おはようございます。監視ツール大好き、インフラ担当の杉内です。

現在進行中のプロジェクトで Mackerel を導入することにしまして、布教という情報共有も兼ねて社内で勉強会をしました。

下記はその時のスライドです。

いくつかポイントを絞って補足します。

監視ツール難しい問題

フィードフォースでは現在下記のような監視ツールを活用しています。

• Nagios
• Cacti
• Zabbix
• AWS CloudWatch

CloudWatchを除いてOSSですがそれぞれ設定が複雑なため、監視ツールの設定を勉強しないとインフラチーム以外では安易に設定できずそれがボトルネックになりつつありました。

また、小規模のサービスだと本格的な監視サーバの構築などはオーバースペックだったりそもそもそこまで手が回らず適切な監視がされていない、といった状態になりがちでした。

Mackerelの良いと思ったところ

• 監視サーバを立てる必要がない
• インストール、設定が簡単
• 基本的なホストの監視はエージェントをインストールしただけで取得できる入れただけで取れる
• プラグインが豊富
• ミドルウェアのメトリクスを取得できる
• UIがこなれていてグラフの見た目が良い

いろいろなメリットが上げましたが「設定が簡単」というのは結構重要だと思っていて、それは「設定が簡単なら自分でも設定できるかも」って思えることですね。
あの監視設定は○○さんじゃないとできないといったことも少なくなり監視ツールに対する属人性も減っていくことを期待しています。

インフラチームとしては監視サーバを構築する、といったタスクが無くなり、より「どういった監視項目にするか」や「通知の閾値をどのくらいにするか」といった点に注力できます。

Mackerelの気になるところ

通知の柔軟性がない点。

連携先は一通り揃っていて十分に感じます。しかし

• mailの送信先が任意に選べない
• slackの通知先チャンネルが1箇所

など、発生したアラートの振り分けまではできません。
今後監視対象のホストやサービスが増えていくと、このServicesの通知はこのチャンネルへ、この監視項目だけは緊急のメーリングリストへといったことがやりたくなるので早くこれらの機能が実装されると嬉しい限りです。(すでにこの辺の機能は追加される予定があるとのこと)

最後に

まだ導入されたプロジェクトはローンチしていませんが現在はテスト環境で稼働中です。本格的な運用が始まったあとに出てくる感想もあると思うのでその時にまた何か書ければと思います。

そして、先日開催された Mackerel Meetup #4 (資料はこちら) でも発表があった通り URL外形監視 や 通知グループ機能 がもうすぐ実装予定とのことなので楽しみに待っていようと思います。