今回は、弊社のインフラを監視しているシステムについて紹介させていただきます。

広告の配信は24時間365日行われなければならないので、一旦配信サーバが落ちてしまうと大変な損害になります。弊社の配信サーバに限らず、止まってはいけないサーバに対しては、ほぼリアルタイムでサーバの状態を監視するシステムが動いていると思います。このような監視システムの例として、 Cacti、Zabbix、Muninなどが知られています。これらのシステムは、サーバの状態を監視および記録し、異常を検知した時には、メールなどで通知を行います。

システムを置き換えるに至ったモチベーション

弊社ではこのシステムとしてCactiを使用していましたが、事業が拡大していくにつれて、監視システムを運用していく面で色々と使いづらくなっていきました。弊社で運用していたCactiの問題点としては、

監視対象のサーバやグラフを増やす事に対して融通が効かない
監視項目を増やすのが大変
アラートの通知が値の高低でしか行えず、メールでしか通知できない

といったものがあり、特に新しいサービスのためにサーバをどんどん追加・転用するようになって来ると、監視対象や監視項目の追加の作業の負担がどんどん大きなものになってしまうという懸念がありました。以上の点から代替のシステムを探して、Sensuという監視システムに行き着きました。 Sensuそのものの説明については他サイトに譲りますが、特に監視項目や監視対象の追加に対してCactiよりも簡単かつ柔軟な対応が可能であるという点でこちらに移行することになりました。

移行の際の課題

CactiからSensuに移行する際には、

Sensuのクライアントを直接導入できないルータなどに対しても監視を行えるようにする必要がある
Sensuそのものは取得したデータの保存およびグラフ化機能を持たないため、別途用意する必要がある

の2点が課題としてありました。

Sensuは基本的に、監視対象のマシンにクライアントを導入して監視を動かすため、Sensu単体でクライアントを導入できないルータの監視を行うのは簡単ではありませんでした。これに関しては、監視をとりまとめるためのサーバ（つまり他に主だったサービスは動いていない）を、ルータの情報を見に行って監視するためのクライアントとして同時に運用することで解決しました。

2に関しては、既に色々なところで、SensuとGraphiteというメトリクス収集およびグラフ描画システムを連携させるための情報がありますが、Graphiteの難しいところとしては、導入が複雑で容易ではないという点があります。弊社でもSensuを新しい監視システムとして使う事を検討した際にGraphiteを導入して試験運用してみたのですが、 Graphiteそのものの導入や設定が難しく、元々動いているCactiから置き換えるコストには見合わないと判断しました。代わりのメトリクス収集ツールとして、deb/rpmパッケージが用意されており導入が楽なInfluxDBを利用する事にしました。 InfluxDBはNoSQLの一種で、時系列データを扱うことに特化したデータベースです。 Sensuからここに保存したデータをGrafanaという可視化ツールでグラフ化しています。

CactiからSensuに移行して嬉しい事

Cacti上で監視対象を増やす際には、当然ひな形から監視対象の設定を作る事ができますが、このひな形は1つしか選択できなかったので、例えば「NginxとMySQLが乗ったサーバの監視を作りたい」と思った時に、「Nginxのひな形＋MySQLのひな形」という形で新しい監視対象を作ることができなかったのです。そのため例えばNginxでとりあえず作り、MySQLの分は手で追加するという事が必要でした。

Sensuでは1つのサーバに複数のタグ付け（Sensu上ではroleといいます）が可能なので、このような問題は起こりません。新しく監視項目が増えた時に、その分だけをあとから追加する事も簡単になりました。

また、Cactiでは実現が難しかった、異常検知時の通知方法を細かく設定することも簡単になりました。弊社ではSlackというチャットツールを活用していますが、特定の異常検知についてはメールと同時にSlackの特定のチャンネルに流すなど、 Cactiではできなかった複数の方法での通知を設定しています。

今回はほとんどツールの紹介のみの記事になってしまいました……