アラート

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

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

命名

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

アラートを出すべきもの

エンドユーザーに影響を与える症状についてアラートを出すことで、可能な限りすべてのアラートを検知しようとするのではなく、アラートの数をできるだけ少なくすることを目指します。アラートは関連するコンソールにリンクされ、どのコンポーネントに問題があるかを容易に特定できるようにする必要があります。

小さな障害に対応するため、アラートに猶予期間を設けます。

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

通常、スタックの可能な限り上位で、高いレイテンシーとエラー率についてアラートを出します。

スタック内の1か所で、レイテンシーについてのみページングします。下位レベルのコンポーネントが遅すぎる場合でも、全体的なユーザーレイテンシーが問題なければ、ページングする必要はありません。

エラー率については、ユーザーに見えるエラーについてページングします。そのような障害を引き起こすスタックの下位にあるエラーについては、個別にページングする必要はありません。ただし、一部の障害がユーザーには見えないが、それ以外に人間の介入が必要なほど深刻な場合（たとえば、多額の損失が発生している場合）は、それらについてページを送信します。

特性が異なる場合、またはトラフィックの少ない種類のリクエストの問題がトラフィックの多いリクエストによってかき消されてしまう場合、異なる種類のリクエストに対してアラートが必要になることがあります。

オフライン処理

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

バッチジョブ

バッチジョブの場合、バッチジョブが十分に最近成功しておらず、それがユーザーに問題を引き起こす場合は、ページングすることが理にかなっています。

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

キャパシティ

即座にユーザーに影響を与える問題ではありませんが、キャパシティに近い状態は、近い将来の停止を避けるために人間の介入が必要となることがよくあります。

メタ監視

監視が機能しているという信頼性を持つことは重要です。したがって、Prometheusサーバー、Alertmanager、PushGateway、およびその他の監視インフラストラクチャが利用可能で正しく実行されていることを確認するためのアラートを設定します。

常にそうですが、原因ではなく症状についてアラートを出すことで、ノイズを減らすことができます。たとえば、PushGatewayからPrometheus、Alertmanager、そしてメールへとアラートが届いていることを確認するブラックボックステストは、各コンポーネント個々のアラートよりも優れています。

Prometheusのホワイトボックス監視を外部のブラックボックス監視で補完することで、それ以外では見えない問題を捕捉でき、内部システムが完全に障害を起こした場合のフォールバックとしても機能します。