Rob Ewaschuk氏のGoogleでの観察に基づいたアラートに関する私の哲学を読むことをお勧めします。
要約すると、アラートをシンプルに保ち、症状をアラートし、原因を特定できる優れたコンソールを用意し、対処すべきことが何もないページを避けることです。
アラートルールの命名に関する厳格な制限はありません。アラート名は、他のラベル値と同様に、任意の数のUnicode文字を含めることができます。しかしながら、コミュニティでは、アラート名にキャメルケースを使用することが推奨されています。
可能な限り少ないアラートにすることを目指し、考えられるすべての原因をキャッチしようとするのではなく、エンドユーザーの痛みに関連する症状をアラートします。アラートは関連するコンソールにリンクし、どのコンポーネントに障害があるかを簡単に特定できるようにする必要があります。
小さな異常を許容するために、アラートに余裕を持たせてください。
通常、スタックの上位層で可能な限り高いレイテンシとエラー率をアラートします。
スタックの1点でのみレイテンシをページングします。下位層のコンポーネントが想定以上に遅くても、全体的なユーザーレイテンシに問題がなければ、ページングする必要はありません。
エラー率については、ユーザーに見えるエラーをページングします。そのような障害を引き起こすスタックの下位層にエラーがあっても、それらを個別にページングする必要はありません。ただし、一部の障害がユーザーに見えない場合でも、人的介入が必要なほど深刻な場合（たとえば、多額の損失が発生する場合）は、それらに関するページを追加します。
異なる特性を持つリクエストの種類、または低トラフィックのリクエストの問題が高トラフィックのリクエストによってかき消される可能性がある場合は、異なるタイプのリクエストに対してアラートが必要になる場合があります。
オフライン処理システムでは、重要なメトリックはデータがシステムを通過するのにかかる時間であるため、それがユーザーへの影響を引き起こすほど高くなった場合にページングします。
バッチジョブでは、バッチジョブが最近十分に成功していない場合にページングすることが理にかなっており、これによりユーザーに見える問題が発生します。
これは一般的に、バッチジョブの2回の完全な実行時間以上である必要があります。4時間ごとに実行され、1時間かかるジョブの場合、10時間は妥当なしきい値です。1回の実行の失敗に耐えられない場合は、ジョブをより頻繁に実行してください。1回の失敗で人的介入は必要ありません。
すぐにユーザーへの影響を与える問題ではありませんが、容量が近いと、近い将来の停止を回避するために人的介入が必要になることがよくあります。
モニタリングが機能しているという確信を持つことが重要です。したがって、Prometheusサーバー、Alertmanager、PushGateway、その他のモニタリングインフラストラクチャが利用可能で正常に実行されていることを確認するためのアラートを設定してください。
常に、原因ではなく症状をアラートすることができれば、ノイズを減らすのに役立ちます。たとえば、PushGatewayからPrometheus、Alertmanager、メールへのアラートが受信されていることをアラートするブラックボックステストは、それぞれ個々のアラートよりも優れています。
Prometheusのホワイトボックモニタリングを外部のブラックボックモニタリングで補足することで、それ以外では見えない問題をキャッチでき、内部システムが完全に失敗した場合のフォールバックとしても機能します。
このドキュメントはオープンソースです。問題やプルリクエストを提出して、改善にご協力ください。