システムの監視ポリシーについて述べる。
監視の定義
あるべき状態が保たれていることを、適切な頻度で確認し続けること。そして保たれなくなったら検知すること。
- あるべき状態の例
- サービスが動いている
- SaaSの費用をちゃんと払っている。そして金額も妥当な範囲に収まっている
- バッチが時間内に終わっている。途中で停止せず処理が最後まで行われている
-> どういう状態であってほしいのかから入る。手段からスタートしない。
- 適切な頻度で確認し続けることの例
- DBの停止や再起動は起きたら即
- WEBサービスの外形監視はN分おき
- 指標のトレンド確認は週次でいいことがほとんど
-> 対応の緊急性に応じて合理的に設定。やりすぎはコストを増やす。
- 保たれなくなったら検知することの例
- 緊急性の高いアラートはメールだけでなく電話も使って受け損ねを防止
- 重要だが緊急ではないエラーのアラートは随時メール
- 重要でも緊急でもないエラーはサマリーレポートを毎日決まった時間に確認
-> こちらも緊急性に応じて受ける方法を用意。監視漏れも監視疲れもよくない
なにを監視すべきか、すべきでないか
監視対象は、まずあるべき姿を洗い出し、そこからどう正常性を確認するのかを考えていく。あるべき姿はプロジェクトの性格によって異なるため、プロジェクトの性格に応じてカスタマイズする。監視内容によってはアプリケーションに可観測性のための機能を持たせる。どんなサービスでもこれだけやっておけば妥当と保証できるチートシートは元から存在しないのであり、手段から対象を決めるべきでない。
監視対象の違いの例)
- B2Cの情報提供系サービス : 24時間365日サービスが落ちないこと、レスポンス速度も妥当であること -> サービスの外形監視、レスポンス速度の監視等
- バッチ処理系のサービス: 処理時間が突き抜けないこと、途中で止まっていないこと、また過去の実施時と比べて極端に取り扱うデータ量が減っていないこと -> 処理時間や実行結果をログでだすようにした上でのログ監視、アプリケーション組み込みの簡易なレポートを定期的に確認する等
また監視は対応とセットである。対応ノウハウの共有のため、可能なものは手順や判断基準をあらかじめドキュメント化しておく。それが難しいものは対応後に記録を残して関係者が（許されるならAIも）いつでも参照できるようにする。
ノイズアラートの防止
不要な監視は行わない。メンバーの疲弊やアラートの見落としを誘発するためである。 このため追加は本当に必要か検討した上で行う。一度追加してしまうと、実際はフォールスポジティブばかりで役に立たないアラートでさえ、責任問題となるリスクにより削除しづらくなる。
まず、アラートの発報を伴う監視は対応可能性とセットで考える。対応不要あるいは対応不能なことに発報すべきでない。
意味のあるアラートの例
- データベース用サーバーのメモリ残量のひっ迫 -> スケールアップやスケールアウト
- 特定IPからの大量不正アクセス -> WAFやアプリケーションにフィルタ追加
意味のないアラートの例
- オートスケールの実行時にアラート -> 対応が必要ない
- AWSのCloudFrontの死活監視 -> 対応できることがない
具体例
ポリシーとしては上記のみであるが、理解の促進のためWEBアプリケーションを例にとって具体例を付け加える。
この場合、まずエンドユーザーつまり利用者にサービスが提供し続けられていること。ひっくり返すと、提供し続けられなくなるような事態になっていないこと（異常検知）、もしくはいずれ重大な障害が出ると予想されないこと（予兆検知）が必要である。この前提で、WEBアプリケーションで各レイヤごとに監視すると例えばこのようになる。
- ユーザー体験: 外形監視、レイテンシ監視など
- アプリケーション: ログ監視、エラー時の直接発報、ジョブキューの過剰滞留など
- インフラ: リクエストのエラー率（5XX）、アプリケーションサーバの稼働数（スケールアウトに関係）、マネージドサービスの強制メンテナンス予定、EOL予定、ドメインや証明書の残り日数など
次にそのサービスを続けていけること。このために具体的にはセキュリティやコストを監視する。
- セキュリティ: 脆弱性、マルウェア、悪意のあるアクティビティなど
- コスト: 通常ではありえない額の課金、Reserved Instance等割引サービスの残り日数など
また監視はアラートだけセットするのではなく、トレンドを見るためのメトリクスとそれをまとめたダッシュボードも用意する。問題の存在を告げるトレンドが出ていたら対応が必要である。例えばレイテンシが悪化していく一方であったり、メモリの残量が下がっていく一方であったりするなら、なんらかの不具合が隠れている可能性が高い。
- CPU使用率・メモリ使用率
- レイテンシ
一方で必要性の薄いアラート、有用性の低いアラートは流さない。