アラート

Rob Ewaschuk氏のGoogleでの観察に基づいたアラートに関する私の哲学 をお読みになることをお勧めします。

要約すると、アラートはシンプルに保ち、症状にアラートし、原因を特定できるように優れたコンソールを用意し、何もすることがないページを避けることです。

命名

アラートルール名の命名に厳密な制限はありません。アラート名は他のラベル値と同様に、任意の数のUnicode文字を含むことができます。しかし、コミュニティは でキャメルケース をアラート名に使用しています。

アラート対象

アラートの数をできるだけ少なくするために、その原因となりうるあらゆる方法を捉えようとするのではなく、エンドユーザーの苦痛に関連する症状にアラートするようにしてください。アラートは関連するコンソールにリンクし、どのコンポーネントが問題であるかを簡単に特定できるようにする必要があります。

小さな一時的な問題に対応するために、アラートに猶予を持たせてください。

オンラインサービングシステム

通常、スタックのできるだけ高いレベルで、高レイテンシとエラー率にアラートしてください。

スタックの1つのポイントでのみページングしてください。低レベルのコンポーネントが遅くても、全体的なユーザーレイテンシが問題ない場合は、ページングする必要はありません。

エラー率については、ユーザーが見えるエラーにページングしてください。そのような失敗を引き起こすスタックの下位にエラーがあっても、それらを個別にページングする必要はありません。ただし、ユーザーには見えないが、人間による介入が必要なほど深刻な（例えば、多額の損失が出ている）失敗がある場合は、それらに対してページングを追加してください。

異なる特性を持つリクエストタイプがある場合、または低トラフィックのリクエストタイプの問題が高トラフィックのリクエストによってかき消される場合、異なるタイプのリクエストに対してアラートが必要になる場合があります。

オフライン処理

オフライン処理システムでは、重要なメトリックはデータがシステムを通過するのにかかる時間です。そのため、それがユーザーに影響を与えるほど高くなった場合はページングしてください。

バッチジョブ

バッチジョブについては、最近正常に完了していない場合、およびそれがユーザーに見える問題を引き起こす場合は、ページングするのが理にかなっています。

これは一般的に、バッチジョブの2回の完全な実行に十分な時間であるべきです。4時間ごとに実行され、1時間かかるジョブの場合、10時間は妥当な閾値でしょう。単一の実行の失敗に耐えられない場合は、ジョブをより頻繁に実行してください。単一の失敗で人間による介入が必要になるべきではありません。

容量

直接的なユーザーへの影響を引き起こす問題ではありませんが、容量に近づくことは、近い将来の停止を避けるために人間の介入を必要とすることがよくあります。

メタモニタリング

モニタリングが機能していると確信できることが重要です。そのため、Prometheusサーバー、Alertmanager、PushGateway、その他のモニタリングインフラストラクチャが利用可能で正しく実行されていることを確認するためのアラートを用意してください。

いつものように、原因ではなく症状にアラートできる場合は、ノイズを減らすのに役立ちます。例えば、PushGatewayからPrometheus、Alertmanager、そしてメールまでアラートが届いているかをチェックするブラックボックステストは、それぞれに個別のアラートを出すよりも優れています。

Prometheusのホワイトボックスモニタリングを外部のブラックボックスモニタリングで補完することは、これまで見えなかった問題を発見するのに役立ち、また内部システムが完全に失敗した場合のフォールバックとしても機能します。