前回の内容を振り返ると、モニタリングシステムは、ユーザーに対して、何が、なぜ壊れたのかに答える必要がありました。その手法には、ホワイトボックスとブラックボックスあり、４大シグナル（レイテンシ、トラフィック、エラー、サチュレーション）に焦点を当てる必要があるということを学びました。
今回は、モニタリングシステムを構築する際の観点について、学びます。
0から作るモニタリングシステム
モニタリングシステムを0から構築するとしたら、何を考えるべきでしょうか？
前回の内容を踏まえると、４大シグナルをモニタリングする必要がまずありそうです。
レイテンシに注目した時、レイテンシの定義は、リクエストを処理して、レスポンスを返すまでの時間なので、その値を測定して、そのまま返せばとりあえずユーザーがレイテンシを観察することはできます。しかし、モニタリングシステムならば、何かしらの値をトリガーとして、通知しないといけないです。通知の基準はどのように設定すべきでしょうか？
最終的に以下のような機能をもつシステムになるかもしれません。
- さまざまなメトリクス、レイテンシの閾値、パーセントタイルによるアラート
- 考えられる原因を検出して知らせるための追加コード
- 考えられる原因のそれぞれに関連するダッシュボード1
適切な粒度の選択
メトリクスやレイテンシ、パーセントタイルの計測にあたって、適切な粒度を選択する必要があります。
以下に過剰となりうる粒度で設定された例が挙げられます。
- 1分ごとのCPUの負荷を観察しても、高いテイルレイテンシを生じさせるスパイクは、それが長時間であっても、見つけられないかもしれません。
- 一方、年間で合計9時間未満の停止時間（年間稼働率99.9%）をターゲットとするWebサーバーの場合、200（成功）のステータスの確認頻度を1分間に1回か2回以上にするのは、やり過ぎでしょう。
- 同様に、99.9%の可用性をターゲットとするサービスのハードドライブの空き容量のチェックは、1分から2分に1回以上にする必要はありません。1
このように、モニタリングしたい値により、適した粒度は異なります。
CPUの負荷を毎秒計測することは、収集、保存、分析のコストが大きくなります。
それほど細かい粒度でなくてもかまわないのなら、粒度を大きくすることでコストを抑えることができます。
シンプルにする、ただしやり過ぎない
モニタリングシステムに限ったことではないですが、システムの要件を積み上げていくと、とても複雑なシステムが出来上がります。
複雑すぎるシステムは、脆く、変更するには複雑で、メンテナンスコストが高くなっていきます。
そのため、モニタリング対象は以下のガイドラインが参考になります。
- 本当のインシデントを最も頻繁に捉えるルールは、可能な限りシンプルで、予想しやすく、信頼できるものであるべきです。
- ほとんど実施されない（例えば、SREチームによっては、四半期に1回未満が目安です）データの収集、集計、アラートの設定は削除すべきです。
- 収集されてはいても、事前に作成されたダッシュボードのいずれにも表示されず、どのアラートにも使われていないシグナルは、削除の候補です。1
##まとめ
- モニタリングの粒度は適切に選択する
- モニタイングシステムは、シンプルに保つ
参考文献
- Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 63-66