今回の内容は、モニタリングの話になります。
モニタリングと言われると、システムがどのような状態であるかを知るために行うというイメージがありますが、その考えは正しいのでしょうか？
まずは、モニタリングを行うその必要性について、見ていきます。
モニタリングの必要性
モニタリングを行う理由として、以下のようなものがあります。
- 長期的なトレンドの分析
- 時間や、実験グループ間での比較
- ダッシュボードの構築
- アドホックな振り返り分析の進行（デバッキングなど）
- アラート
モニタリングを行うのは、ビジネスの需要を予測したり、システムの問題を抽出したり、システムの状態を把握ことなどが主な目的であるとわかります。
また、モニタリングした結果に問題がある場合は、それを人間に通知しなければなりません。特に今回は、このアラートについて考えます。
この通知（アラート）は問題が起きたときには、すべてを通知すべきなのでしょうか？もちろん、重大な問題であれば、それを通知することは必要です。しかし、「単に何か少しおかしい」程度では、通知すべきではないです。
仮にそのようなものを通知するようにした場合、その通知は、睡眠中や休日にも割り込むことになります。割り込みタスクが多すぎると、人は、それを表面的に見るだけになったりしてしまいます。慢性化すると、本当に重大な問題を見逃すかもしれません。
そのため、効率的なアラートとは、質の高いシグナルを送り、あまり重要でないもの（ノイズ）を抑えたものである必要があります。
では、モニタリングで通知を行う際に設定する値はどのようなものが妥当なものなのでしょうか？
モニタリングにおける妥当な期待値の設定
モニタリングの結果により、ユーザーが問題の根本原因に素早くたどり着くことが重要です。なので、モニタリングシステム自体の複雑さによって、ユーザーを混乱させてしまうことは避けるべきです。
Googleでは、シンプルで高速なモニタリングシステムを指向しているそうです。
シンプルとは、例えば閾値を学習したりや因果関係を自動的に検出するようなシステムを避け、単純なルールに基づいて、問題の検出を行うということです。
それにより、特定の明白で重大な異常を高速に検出することになります。
まとめ
今回は、短いですが、ここまでになります。
次回は、問題の切り分けを行う際の基本的な考え方やその実際の方法について、見ていきます。
雑記
- 質の高いシグナルを出す必要がある。
- 通知を出すルールは明白であるべき。
- 書籍の中でちょくちょく人間を客観視した視点でかかれている箇所があるが、ミスしがちな点や癖を考慮して、仕組み作りをした方が自然なものが出来上がる気がします。
参考文献
- Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 57-60