小さな会社で一人で監視サーバ立てて運用して一年以上たったのでそのまとめ

MECE目指して書き始めたけど全然無理でした。多分、初心者向けです。
仕事で書いたドキュメントの流用です。
会社にはインフラでズバッと意見を出す人がいないので、こういう割と広いこと見れてそうな入門ドキュメントを会社のドキュメントとしてためておくことで、将来誰か監視システムを刷新するときとかの方向性になれればという考えです。

持つべきか、もたざるべきか

まず大枠の設計として、監視システムを持つべきか、持たざるべきかという点について考える必要があると思います。
これは監視をするかしないかという意味ではなく、監視システムのサーバを持つかどうかという意味を指します。
つまりZabbixやmuninといった監視サーバを構築して運用していくのか、それともMackerelやNew Relicといった SaaS監視システムにお金を払って利用するのか、という監視システム運用の方向性の問題です。

私の場合は、会社でインフラエンジニアが私一人だったので、私の興味からZabbixを立てることにしました。
Zabbixに惹かれたのは主に「ネット上に先人の記事がそれなりに上がってる」「カスタムスクリプト書けばなんでもできる」「成長したイケてるベンチャーも使ってて実はダサくない」という3点で、とくにスクリプトを書けばなんでもできそうというのは、私自身のコーディング経験の足しにもできるし、アプリケーションエンジニアにも説明すれば監視業務にコミットしてもらえそうという期待からでした。

 CTOは新しくてイケてるSaaSを使うのが大好きだったので、実はすでにNew Relicが入っていました。しかし有料プランは結構高く、財布事情が許してくれなかったので、私の提案をしぶしぶ飲んで、Zabbixとの並行運用になりました。
そしていま運用して一年ちょいになりますが、Zabbixでできることが増えてきたので、New Relicはほとんど見ていません。
エージェント自体は残っているけど…。

監視システムに欲しい機能

監視システムには下にあげる機能が基本的に存在しているでしょう。
一部の特化型システムにはないものもあるかもしれないですが…。
そして、それらができるだけ自動化されていることが望ましいです。
ここでいう自動化とは、少ない手作業で必要な多くの作業をこなしてくれるという意味を含みます。　

• 監視対象サーバ登録削除編集
• 監視対象サーバの監視有効無効化
• 監視項目追加削除編集
• 閾値に応じたアラートの登録削除編集
  • 監視システムの画面上で表示
  • メール通知
  • 電話通知
  • スマートフォンアプリケーション通知（チャットとか）
• 監視結果のグラフ表示
• 複数のサーバのグラフを一元表示
• カスタム（自作）スクリプト実行
• カスタム（自作）監視項目追加削除編集
• ユーザ複数作成と各ユーザの利用権限編集
• 監視結果グラフをパッと見れるダッシュボード

やっておきたい連携

メール連携

原始的だけど社会人だったら誰でも理解できる説明がもっとも容易な連携。 

私の場合はZabbixのサーバにPostfixを入れて運用する様にしてしまったけれど、今から作り直すならSESのスタック立ててZabbixはそこを使う様にするかな…。
ついでにACMも認証させてSSL証明書もゲットしておくと尚よし。

チャットシステムとの連携

具体的には、Slack、HipChat、ChatWorkなど。
私の勤務先ではSlackを使っており、かつ有料プランになっているので、メール連携が使えたのでそれを使っています。
コードを書かずに連携できて超ラクです。ありがたや。

設定を行うとSlackからメールアドレスが発行されるので、それをZabbixでアラート通知用メールアドレスとして使用するだけです。
かんたん。

 障害、復旧、閾値オーバー、レスポンス速度悪化、バッチジョブ開始、バッチジョブ完了、サーバ新規追加、などをメール連携でSlackに飛ばす様にしていますが、開発チームみんなに全部投げるのもアレなので、何個かチャンネル分けて、たとえばたくさんの人がみる監視チャンネルには障害やジョブ失敗のアラートのみを投げる様にしています。
そんで、ジョブ成功とかは私だけが入ってるチャンネルを作ってそこに流したり。
半日単位とかでガーっとスクロールして流し見したりします。

電話連携

実はできていません…。
データセンターがメルアドを持っているので、そこにメール送って電話させようぜという人力電話連携構想が社内で湧いており、とりあえずそれでいっかな…。
そのうちTwillio連携とかさせたい。
優先度低い。

分けられる要素はできるだけ別インスタンスにしたい

たとえば私の場合はAWS上にZabbixを立てたわけですが、DBはRDSを利用しています。
その方がDBで心配する確率が減っていいです。
同様にメールサーバもZabbix内に立てるのではなく、SESなどを使った方がいいです。
その辺はケチったところで運用のための監視サーバのための運用がつらくなるだけなので、ある程度お金を使わせていただきたい…。

インフラエンジニア以外に使ってもらうにはお膳立て必須

• ログインしてぱぱっと問題ないかを確認するまでの手順
• 全体の状況を一覧で見れるダッシュボードへのアクセス手順
• そういうダッシュボードの作成
• チャットアプリに飛んでくるメッセージの意味と対処方法
• よくある障害の内容と復旧方法

私の場合は多分まだ全然足りてなくて、10割オペレーションが7.5割に減ったくらいかな…。
マネージャーの上司にZabbixのスクリーンを教えたら自分でグラフ組み立てて性能レポート画面作ってたのはいい結果だったかなと思います。

障害対応とかはアプリケーションエンジニアにも少しずつシェアできると万々歳なんだけどそもそもPCを持ち帰っていないとか色々あるので私が対応…といってもサーバ多めにしてたりするので正統派なシステムダウンはもう全然起こっていません。
平日に利用者からくるアプリケーション不具合やデータ不整合に関する問い合わせ調査なんかはむしろ他のエンジニアにやってもらっているので、多分それでバランスはとれています…。

監視項目や検知内容は育てる前提で

監視項目はググって引っ張ってきていいと思いますが、まずは基本的に

• CPU使用率
• メモリ使用率
• ロードアベレージ

を見ておけばいいのかなと思います。そしてそれらの使用率高騰のアラートを設定しておく。
DBは上記に加えて、

• コネクション数
• ストレージ残容量

なども必要ですね。気づいたらディスクがいっぱいでDB停止からのサービス停止とか怖いですね。
Webサーバのプロセス処理方式が Prefork の場合には

• 稼働プロセス数

も監視しておいた方がいいですね。利用者が増えてくるとそこがボトルネックになることもあると思います。
それから運用しているWebサービスの主要エンドポイント（URL）の

• レスポンスタイム
• レスポンスコード

を見ておきましょう。
POSTが送れる場合はテストユーザでのログインとかをZabbixにやらせることもできると思いますので、そこでエラーコードが帰ってきたらログイン機能がトラブル！？みたいな検知もできるかなと思います。

手に入れた値はCloudWatchに寄せるのか、監視スステムに寄せるのか

AWS特有の悩みです。どっちかに決めるしかないです。悩ましいことにどっちもお互いにインポートすることができます。
私の場合は、CloudWatchは課金しないと2週間分しかログが残ってくれないので、一年単位でのトレンド分析とかそういうのには向いてなさそう…という理由でZabbix側に寄せることにしました。
つまり、CloudWatchが持ってる値のうち欲しいものをスクリプト書いてそいつに持ってこさせます。
するとZabbix側で好きにアラートやアクションを設定していろいろ処理することができます。
というかそういうことやらないとわざわざZabbix立てる意味はない…。

プロセス自動復旧

Zabbixの場合は、ダウンを検知したらZabbixからコマンド実行命令を出して復旧させることで自動復旧が実現できます。
私の場合はまだまだ導入が少ないので増やしていきたいところ…。

Mackerel使わないの？

なんか料金とインベントリ数だったかグラフ数だったか外形監視数だったかのコスパを考えると見合わないかなぁと思って検討をやめました。
プログラマフレンドリーっぽいので私がいなくなったらアプリエンジニアたちが乗り換えるかもしれません？？

以上。
ある程度監視項目とか増えてきて回り始めると他のことに時間を取られて監視システムの成長が鈍化するのがつらいところ。
仲間が欲しい。