- モニタリング、アラートの基本原則とベストプラクティス
- アラート発生時に人間にページを送るべき問題と送るべきではない問題の切り分け、対処方法
言葉の定義。
-
モニタリング
- システムに関するリアルタイム定量データの収集、処理、集計、表示
-
ホワイトボックスモニタリング
- システムの内部によって公開されているメトリクスに基づくモニタリング
- リトライなどによりマスクされてしまっている障害など、近々生じることになりそうな問題
-
ブラックボックスモニタリング
- ユーザーが目にする振る舞いをテストする
- 予測ではなく、実際に起きている問題
-
ダッシュボード
- サービスの主要メトリクスのサマリビューを提供するアプリケーション
-
アラート
- 人間に読まれることを意図した通知
-
根本原因
- ソフトウェアの欠陥やヒューマンエラーで、修正されれば同じことが起こらないと確信できるもの
-
ノードとマシン
- 物理サーバー、仮想マシン、コンテナで動作しているカーネルの１つのインスタンス
-
プッシュ
- サービス動作中のソフトウェア、あるいはその設定に対する変更
なぜモニタリングするのか？→
- ビジネス分析への生データの提供
- セキュリティ侵害の分析の支援
-
長期的なトレンドの分析
- どういったペースでシステムが大きくなってきているのか？
- 日時のアクティブユーザー数の増加ペース
-
時間や、実験グループ間での比較
- どちらのクエリが高速か？
- memcacheのヒット率は？
- サイトの速度は、先週と比べてどうか？
-
ダッシュボードの構築
- サービスに関する基本的な疑問に答える
- ４大シグナル（レイテンシ、トラフィック、エラー、サチュレーション）
-
アドホックな振り返り分析の進行（デバッギングなど）
- レイテンシが急上昇したが、他に何か同時期に発生していたか？
-
アラート
- 誰かが早めに確認すべきであることを通知
- システムが自身を自動修復できない場合→人間がそのアラートについて調査→本当に問題があるのかを判断→問題に対処→根本原因を判断
- 単に「何か少しおかしい」程度でアラートを発生させない
- 効率的なアラートのシステムは質の高いシグナルを発する。ノイズを極めて低く抑える。
- ページの発生が頻繁になりすぎるとノイズに紛れた本物のページを見落とす。
- シンプルで高速なモニタリング
- 自動的に因果関係を検出するようなことは避けている
- 複雑な依存関係は基本的にはメンテナンスしない
- 問題発生→人間へのページ→基本的な切り分け→デバッギングに至るクリティカルパスをチーム全員でシンプルかつ包括的なものに保つことが重要
- 人間へのアラートを発生させるルールは、理解しやすく、明確な障害を表現するものであること
何が壊れたのか？なぜ壊れたのか？ →シグナルを最大化し、ノイズを最小化する上でもっとも重要な区分
-
ブラックボックスモニタリング
- 予測ではなく、実際に起きている問題
- 症状を扱うものになることもあれば、原因を扱うものになることもある
- 人間の手を患わせることを、実際に発生している問題のみに限定できる。
-
ホワイトボックスモニタリング
- リトライなどによりマスクされてしまっている障害など、近々生じることになりそうな問題
- ある担当者にとっての障害が別の担当者にとっての原因になることがある
-
レイテンシ →リクエストを処理してレスポンスを返すまでにかかる時間
- 成功時のレイテンシと失敗時のレイテンシを区別することが重要
-
トラフィック →システムに対するリクエストの量
-
エラー →処理に失敗したリクエストのレート
- 明示的なエラー（５００エラー）
- 暗黙的なエラー（２００返ってきているけど、意図しない結果）
- ポリシーによるエラー（サービスレベルを満たさない）
-
サチュレーション →サービスがどれだけ手一杯になっているかを示す。
- 何らかの量の平均値に基づくモニタリングシステムは危険。
- 平均値ではなく、バケット化した値を収集し、ヒストグラムで分布の様子をモニタリングする。
システムの様々な側面は、粒度のレベルを変えて測定すべき。 収集・記録に極端なコストをかける必要はない。
モニタリングシステムも複雑になりすぎると、メンテナンスが負担になってしまう。
モニタリング対象を設計する上でのガイドライン
- 可能な限りシンプルで、予想しやすく、信頼できるものであるべき
- ほとんど実施されないデータの収集、集計、アラートの設定は削除すべき
- 収集されていてもダッシュボードに表示されず、アラートにも使われていないシグナルは削除候補
モニタリングシステムも、別々のシステムは疎結合に保つべき
ルールの決め方。 モニタリングやアラートのルールを作成する際は以下の質問をする
- そのルールなしでは検出されない状況で、緊急で対応が可能で、現時点あるいは将来的にユーザーに影響を与えるか？
- そのアラートは対応せずにそのままにしておけるか？→どういった理由でそのアラートは無視できるのか？
- そのアラートはユーザーに悪影響を与えているか？→悪影響を与えていないのなら除外すべき。
- そのアラートに対してアクションを取ることができるか？そのアクションは緊急なのか？そのアクションは自動化できないか？そのアクションは長期間にわたり効果を持つか、短期間だけの回避策か？
- その問題でページを受ける人は他にもいるか？
ページ及びページャーに関する基本哲学
- ページが来るたびに緊急事態という感覚を保って対応する
- 具体的な対応が可能
- 対応に知性が必要→ロボット的なレスポンスを返すだけであれば、ページすべきではない
- 新たな問題か、これまでに見たことがないイベントに関するものであるべき
この見方によって、原因よりも症状を捉えることに労力を費やした方が良いことが明確になる。 原因については、本当に明確で、非常に差し迫ったものだけを心配する。
モニタリングに関する判断は、長期的なゴールを念頭に置くことが重要
一つひとつのページに人が対応する→システム改善に充てる時間がなくなる システムの長期的な展望を改善するために可用性やパフォーマンスの短期的な低下を受け入れることもしばしばある。
アラートを一時的に緩めることによって、より早くサービスを改善できた。
本当の修正を行う代わりに、問題を覆い隠すようなパッチを当てることで、メンテナンス不能な技術的負債を構築してしまうことは簡単に起こり得る
機械的でアルゴリズム的なページは警告フラグ。 →チームの一部がこうしたページを自動化しようとしないのであれば、自分たちの技術的負債を消し去る自身を失っている状態。
短期的な可用性 vs 長期的な可用性 コントロールされた短期的な可用性の低下は、苦痛を伴うものの、システムの長期的な安定のための戦略的なトレードオフ
重要なのは、個別のページではなく、ページ全体のレベルが健全で持続可能なチームと長期的な展望をもたらし、健全で適切な可用性を持つシステムへと繋がるということ。
ページ頻度に関する統計情報を経営者とともにレビュー →ページの負荷と配下のチームの全体的な健全性に関し、意思決定者が最新の情報を把握できること
オンコールのローテーションとプロダクトを成功に導くために、発生した症状や差し迫った本物の問題に対するアラートを選択し、実際に達成可能な目標にターゲットを合わせ、モニタリングシステムが素早い診断を確実に支援できるようにすること。
- 長期的な視点が重要
- 技術的な負債を経営陣といかに共有するかが重要
- サービスレベルをどのように定義するかが重要→サービスレベル目標ってみなさんどう決めていますか？
- 平均値ではなく、ヒストグラムで分布を分析することが大事。→レイテンシのサービスレベル指標など平均値で決めてしまっている。
- diffeasyではMackerelで、FATALエラーログを監視、CPU、メモリ、ディスク容量などの閾値を超えた場合にSlackに通知→一部通知はノイズ化しつつある。
- 収集・通知すべきページの選定が重要