アラートのベストプラクティス - Prometheusドキュメント

このページはPrometheus公式ドキュメント和訳+αの一部です。

Alerting

Googleで見たことに基づくRob EwaschukのMy Philosophy on Alertingを読むことをお勧めする。

まとめると、アラートをシンプルに保つ、症状についてアラートする、原因を特定できるように良いコンソールを持つ、何もすることがない呼び出しを避けることである。

何についてアラートするか

苦痛を起こし得る可能性全てを捉えようとするのではなく、エンドユーザーの苦痛に結びついた症状についてアラーティングすることで、可能な限り少ないアラートが来ることを目指すこと。

Allow for slack in alerting to accommodate small blips.

online-servingシステム

一般的に、可能な限り高いレイヤーのレイテンシーとエラー率についてアラートすること。

スタックの1箇所のレイテンシーについてのみ呼び出しを行うこと。 低レベルのコンポーネントが遅くても、全体としてのレイテンシーが良好なら、呼び出しをする必要はない。

エラー率に関して、ユーザーに見えるエラーについて呼び出しを行うこと。 そのようなエラーを引き起こし得る下位レイヤーのエラーが起きていたとしても、個別にそれらについて呼び出しをする必要はない。 ただし、あるエラーが、ユーザーには見えなくても、人間の対応が必要なぐらい深刻(例えば、金銭的な損失が大きい)なら、それらについて呼び出しを追加すること。

リクエストが種類によって異なる特徴を持つなら、それらに対して異なるアラートが必要になるだろう。 そうしなければ、トラフィックの少ない種類のリクエストの問題は、トラフィックの多いリクエストに埋れて消えてしまうだろう。

オフライン処理

オフライン処理システムに対しては、鍵となるメトリックは、データがシステムに入ってから出るまでにどれぐらいかかるかである。 したがって、それがユーザーに影響を与えるぐらいまで高くなったら、呼び出しをするべきである。

バッチジョブ

バッチジョブに対しては、直近で十分に成功しておらずユーザーに見える問題を起こしそうな場合に呼び出しを行うのが合理的である。

これは、バッチジョブ実行全体の少なくとも2回分に十分な時間にするべきである。 4時間ごとに実行され1時間かかるジョブに対しては、10時間が合理的な閾値であろう。 もし、一回の実行の失敗も耐えられないのであれば、一回の失敗で人間の介在が必要とならないように、ジョブをもっと頻繁に実行すること。

キャパシティ

ユーザーへの影響をすぐに起こす問題ではないが、キャパシティに注意することは、近い将来の不測の事態を避けるために、しばしば人間の介在を必要とする。

メタ監視

監視が動いていると確信を持つことは重要である。 したがって、Prometheusサーバー、Alertmanager、Pushgatewayおよびその他の監視インフラが正しく動いていると保証するためにアラートするべきである。

いつものように、原因ではなく症状についてアラートすることが可能ならば、そうするのがノイズを減らすことに繋がる。 例えば、アラートがPushgatewayからPrometheusとAlertmanagerを通ってメールまで届くことのブラックボックステストは、それぞれに対する個別のアラートよりも良い。

Prometheusのホワイトボックステストを外部のブラックボックス監視で補うことで、そうしないと見つけられない問題を検出する可能性がある。 また、内部システムが完全に失敗している場合の最後の拠り所として働く。

参考リンク

おすすめ書籍

入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

入門 Prometheus ―インフラとアプリケーションのパフォーマンスモニタリング

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

和訳活動の支援

Prometheusドキュメント和訳が役に立った方は、以下QRコードからPayPayで活動を支援して頂けるとありがたいです。

PayPayによる支援用QRコード
上のQRコードからPayPayによる支援