はじめに
「いま運用しているシステムの監視機能が停止したとき、システム障害をどのように検知するか」という問いに答えられますか？
本記事では監視機能の監視というテーマについて、具体的なパターンとトレードオフを解説します。
「監視機能の監視」がなぜ必要か
監視システムには以下のような単一障害点（SPOF）が潜んでいます。
- 通信経路の遮断 通知先（チャットツールやメールサーバーなど）へのネットワーク不通、APIレートリミット超過、通知設定ミスなど
- 監視エージェントの停止 サーバー上でメトリクスを収集・送信するエージェントが停止し、メトリクスが送信されなくなる
- 広域障害発生 監視機能が監視対象システムと同じリージョンで稼働している
これらはアラート閾値に達しないため「正常だからアラートがないのか、監視機能が停止しているからアラートがないのか」の判断ができません。
「監視機能の監視」を実現する3つの設計パターン
この課題を解決するため、システム設計では主に以下の3つのアプローチがあります。
パターン1：デッドマンズスイッチ
監視システムから定期的に「生存信号」を外部（チャットツールなど）に送り、途絶えたら異常とみなす。ただし、送信先のシステムは同じリージョンで稼働してはいけない。
パターン2：外形監視
監視機能を外部から定期的に通信し、応答があるか監視する。インバウンド通信が発生するため、認証やエンドポイントの実装が必要。
こちらのパターンも監視機能と同じリージョンで稼働してはいけない。
パターン3：マルチクラウド/サードパーティによる監視
例えばAWSの監視にDatadogを、Datadogの監視にAWSを使うといった相互監視をする。異なるサービスを利用するため運用負荷とコストが増加する可能性がある。
トレードオフについて
「監視の監視」を強化すればするほどシステムの信頼性は上がりますが、監視システムが複雑になると、誤検知（偽陽性）や膨大なアラートによって運用負荷が高くなる傾向にあります。また外部SaaSのライセンス費用や、外形監視の実行ログ保存費用などが蓄積されます。
サービスが停止した際のビジネス影響度（SLA）と運用予算と人的リソース、これらを天秤にかけ、「ここまではシステムで自動検知する」という境界線を明確に引くことが重要です。
おわりに
皆さんが関わっているシステムでは、監視機能の監視はどのような設計になっていますか。検討できていないのであれば一度見直してみてはいかがでしょうか。
