サービスレベル目標（SLO）にアラート ポリシーを作成して、SLO に違反する可能性があるかどうかを知らせることができます。モニタリングする SLO を選択してから、その SLO をモニタリングするためのアラート ポリシーを構成します。条件は通常、違反を構成するしきい値と違反が許可される期間を選択することで表します。許容期間を超えてしきい値を超過した場合、アラート ポリシーがトリガーされます。
このページでは、エラー バジェットのバーンレートに関するアラートについて説明します。ただし、アラート ポリシーの詳細は説明しません。条件と通知チャネルに関する基本的なコンセプトをすでに理解していることを前提としています。
アラート ポリシーの概要と作成方法については、アラート ポリシーの使用をご覧ください。
SLO ベースのアラート ポリシーを作成する具体的な手順については、以下をご覧ください。
- Google Cloud コンソールを使用してアラート ポリシーを作成する。
- Cloud Monitoring API を使用してアラート ポリシーを作成する。
エラー バジェットのバーンレート
コンプライアンス期間のエラー バジェットは、（1 - SLO 目標）×（コンプライアンス期間の有効イベント）です。SLO 目標が 95% の場合、SLI で測定されたイベントの 5% が失敗するまでは SLO の目標が達成と認められます。
バーンレートは、コンプライアンス期間中にエラー バジェットを消費する速度を示します。バーンレートは、対象となるイベントの数と、コンプライアンス期間中に受信したエラーイベントの数によって異なります。たとえば、エラーイベントが発生していない場合、エラー バジェットは消費されず、バーンレートはゼロになります。すべてのリクエストが失敗した場合のサービスの最大ダウンタイムを計算する方法については、SLO バーンレートをご覧ください。
バーンレート指標は正規化されています。バーンレートが 1 より大きい場合、測定されたエラー率が今後のコンプライアンス期間でも維持されると、その期間、サービスは SLO から逸脱した状態になります。詳細については、エラー バジェットをご覧ください。
バーンレート指標は、時系列セレクタ select_slo_burn_rate によって取得されます。バーンレートのアラート ポリシーは、アラートのコンプライアンス期間中の測定により、定義済みのしきい値よりも速くエラー バジェットが消費された場合に通知されます。時系列セレクタは他にもあります。SLO データの取得をご覧ください。他の時系列セレクタを使用するアラート ポリシーは作成できますが、Cloud Monitoring API を使用して作成する必要があります。
SLO でのアラート ポリシーの作成の概要
SLO のアラート ポリシーの作成方法は、指標のアラート ポリシーの作成方法と似ています。このセクションでは、アラート ポリシー作成の一般的な手順について確認します。
SLO のアラート ポリシーを作成する手順は次のとおりです。
アラート ポリシーのベースとなる SLO を特定します。
選択した SLO を使用するアラート ポリシーの条件を作成します。この条件では、SLO データの取得に使用する時系列セレクタを指定します。また、SLO がいつポリシーを遵守しない状態になったかを判定する期間、しきい値、比較も指定します。
たとえば、時系列セレクタをバーンレートに使用すると、取得したデータに選択した SLO のエラー バジェットのバーンレートが反映されます。
この条件でも、アラートをトリガーする前に SLO のしきい値と違反の存続期間を指定することになります。たとえば、アラートをトリガーする前に一定期間、バーンレートを一定の割合以上にするとします。some amount over の値は条件のしきい値、some period の値は条件の期間です。
アラート ポリシーで使用する通知チャネルを特定または作成します。
アラート ポリシーの原因をユーザーに説明するドキュメントを提供します。
アラート ポリシーの概要と作成方法については、アラート ポリシーの使用をご覧ください。
アラート ポリシーとルックバック期間
アラート ポリシーの SLO データを取得する場合は、SLO の識別子とルックバック期間を指定します。ルックバック期間は、過去のどの時点までのデータを取得できるかを示します。重要なのは、ルックバック期間が SLO のパフォーマンスとエラー バジェットを計算するためのコンプライアンス期間としても使用されることです。
現時点では、24 時間を超えるコンプライアンス期間を適用して、SLO のエラー バジェットの消費率に基づきアラートを発信することはできません。多くの場合、サービス停止を検出して短期運用でこれに対応するためには、長期（28 日～30 日など）のコンプライアンス期間を 24 時間未満の 1 期間に近づければ十分です。
コンプライアンス期間を短くすると問題を迅速に検出できますが、1 日のなかのトラフィックとエラーレートの大きな変化により、トラフィックの少ない期間にアラートが発生しやすくなります。1 をかなり超えるバーンレートのしきい値を使用して、これらの時間帯にアラートの感度を下げることを検討してください。
エラー バジェットのアラートの種類
アラート ポリシーを設定してエラー バジェットをモニタリングする場合は、2 つの関連するアラート ポリシーを設定することをおすすめします。
急な消費量の急激な変化を警告する急速バーンアラートは、修正をしないと間もなくしてエラー バジェットを使い果たしてしまいます。「このレートでは、1 か月のエラー バジェットが 2 日でなくなってしまう！」という状態です。
急速バーンアラートでルックバック期間をより短く設定すると、短い時間であっても、良好でない状態が発生し、継続した場合、直ちに通知が送信されます。本当に良好な状態でない場合、通知を長い時間控える必要はありません。
ここで通知する消費率のしきい値は、ルックバック期間の基準値よりもかなり高くなります。
低速バーンアラートは、アラートを発生させないと、コンプライアンス期間の終了前にエラー バジェットを使い切る場合に、消費率についてのアラートを発生させます。低速バーン状態は、急速バーン状態よりも緊急性が低くなります。「今月の予定は少し上回っているが、今のところ大きな問題はない」という状態です。
低速バーンアラートでは、より短期間の消費量のばらつきをならすために、より長いルックバック期間を適用します。
低速バーンアラートでアラートを発するしきい値は、ルックバック期間における理想的なパフォーマンスよりは大きくなりますが、大幅に上回るわけではありません。ルックバック期間が短く、しきい値が高いポリシーは、長期的な消費量が横ばいになってもアラートが多量に発生してしまう可能性があります。しかし、消費量が長期的に高い値を維持した場合、最終的にすべてのエラー バジェットが消費されてしまいます。
次のステップ
- Google Cloud コンソールを使用して SLO ベースのアラート ポリシーを作成するには、アラート ポリシーの作成（Google Cloud コンソール）をご覧ください。
- Monitoring API を使用して SLO ベースのアラート ポリシーを作成するには、アラート ポリシーの作成（API） をご覧ください。