概要

SLO バーンレートアラートは、SLO エラーバジェットの消費率が指定した閾値を超え、それが特定の期間継続した場合に通知されます。たとえば、SLO の 30 日間目標に対して、過去 5 分間で過去 1 時間に 14.4 以上のバーンレートが測定された場合にアラートを設定できます。また、アラートが必要な閾値より少し低い閾値、例えば 7.2 以上のバーンレートが観測された場合にオプションで警告を出すように設定することができます。

Note: Burn rate alerts are available for the following SLO types:

• Metric-based SLOs,
• Monitor-based SLOs that are only composed of Metric Monitor types (Metric, Integration, APM Metric, Anomaly, Forecast, or Outlier Monitors), and
• Time Slice SLOs

バーンレートアラートの仕組み

バーンレートとは、Google の造語で、SLO の目標長に対してエラーバジェットがどの程度速く消費されるかを示す単位なしの値です。たとえば、30 日間を目標とする場合、バーンレートが 1 であれば、1 の割合が一定であれば、エラー予算がちょうど 30 日で完全に消費されることを意味します。消費率 2 とは、一定であれば 15 日、消費率 3とは 10 日でエラーバジェットが枯渇することを意味します。

この関係は以下の式で表されます。

$${\text"SLO 目標の長さ" \text" (7、30 または 90 日)"} / \text"バーンレート" = \text"エラーバジェットが枯渇するまでの時間"$$

バーンレートアラートは、観測されたバーンレートを測定するために、最近の「エラー率」を計算に使用します。「エラー率」とは、ある期間の全動作に対する不良動作の比率を意味することに注意してください。

$$\text"エラー率" = 1 - {\text"期間中の良好動作" / \text"期間中の全動作"}$$

「動作」の単位は、SLO の種類によって異なります。メトリクスベースの SLO は、何かの発生数 (成功したリクエストや失敗したリクエストの数など) を追跡し、モニターベースの SLO は、時間の量 (モニターのダウンタイムやアップタイムなど) を追跡します。

SLO の目標 (99.9%など) を設定する場合、エラーバジェットは、どの程度の信頼性の低さを許容するかということです。

$$\text"エラーバジェット" = 100% - \text"SLO 目標"$$

言い換えれば、エラーバジェット (分数形式) は、維持すべき理想的なエラー率です。つまり、バーンレートは理想的なエラー率の倍率と解釈することもできます。たとえば、30 日間 99.9% の SLO の場合、バーンレートが 10 であれば、エラーバジェットは 3 日で完全に枯渇するペースであり、観測されたエラー率は理想的なエラー率の 10 倍であることを意味します。

$$(\text"バーンレート") (\text"理想的なエラー率") = \text"観測されたエラー率"$$ $$(10)(0.001) = 0.01$$

理想的には、SLO の目標期間中、常にバーンレート 1 を維持するようにします (新機能でアプリケーションを進化させるために投資する際)。しかし、実際には、問題やインシデントによって、問題が解決されるまでの間、バーンレートが急激に上昇するため、バーンレートは変動することになります。したがって、バーンレートに関するアラートを使用すると、問題がエラーバジェットを消費する割合が高くなり、SLO の目標を達成できない可能性がある場合に、積極的に通知されるようになります。

バーンレートアラートを構成する場合、バーンレートの閾値と、観測されたバーンレートを測定する「長いアラートウィンドウ」と「短いアラートウィンドウ」を指定します。長いアラートウィンドウは時間単位で指定し、重大な問題に対応するのに十分な長さの期間にわたってバーンレートを測定するようにモニターを設定します。これにより、軽微な問題によってモニターが薄っぺらなアラートを発するのを防ぐことができます。短いアラートウィンドウは、分単位で指定されます。これは、最近のバーンレートがまだ閾値を上回っているかどうかを確認することで、実際の問題が終わった後、モニターが迅速に回復することを保証します。Google は、短いウィンドウを長いウィンドウの 1/12 にすることを推奨しています。しかし、Datadog では API や Terraform を使ってプログラムで短いウィンドウをカスタマイズすることができるようになります。以下は、バーンレートアラートがどのように評価されるかの完全な計算式です。

$$(\text"長いウィンドウのエラー率" / {1 - \text"SLO 目標"} ≥ \text"バーンレートしきい値") ∧ (\text"短いウィンドウのエラー率" / {1 - \text"SLO 目標"} ≥ \text"バーンレートしきい値") = \text"アラート"$$

最大バーンレート値

上述したように、この式を使って、長いウィンドウと短いウィンドウの両方で観測されたバーンレートを評価することができます。

$$\text"エラー率" / {1 - \text"SLO 目標"}$$

これまでに観測されたエラー率の最大値は 1 です (例えば、ある時間帯に全体の 100% が不良動作であった場合)。つまり、バーンレートアラートで使用できるバーンレートの最大値が存在することになります。

$$\text"最大バーンレート" = 1 / {1 - \text"SLO 目標"}$$

SLO 目標値が低いほど、可能な最大バーンレート値も低くなります。この値より高いバーンレートの閾値を設定しようとすると、アラートが作動することは不可能になります。バーンレートアラートの条件を上記の式で決定される最大値よりも高い値に設定すると、SLO に 100% を超えるエラー率が発生したときに通知するようにバーンレートアラートに指示することになります (これは不可能です)。そこで、役に立たないアラートが誤って作成されるのを防ぐため、Datadog は、最大値を超えるバーンレート値を設定するバーンレートアラートの作成をブロックしています。

バーンレート値の選択

アラートを発するためのバーンレート値の選択は、SLO が使用する目標とタイムウィンドウに依存します。バーンレートアラートを構成する場合、バーンレート閾値自体の設定と長いウィンドウの設定に主に焦点を当てるべきです。Datadog は、Google が提案するように、最初は短いウィンドウを長いウィンドウの 1/12 に保ち、アラートを使用した後に必要に応じて値を調整することを推奨します。可能な最大バーンレートは、前のセクションで説明した関係によって制限されます。

アプローチ #1: エラーバジェット枯渇までの時間

バーンレートの閾値については、先ほどの関係を思い出してください。

$$\text"SLO 目標の長さ (7日、30日、90日)" / \text"バーンレート" = \text"エラーバジェットが完全に消費されるまでの時間"$$ バーンレートを求め、重要な問題と認定されるエラーバジェットが完全に消費されるまでの時間を選びます。

長いウィンドウでは、軽微な一過性の問題ではなく、実際の問題を示すために、高いバーンレートが持続しなければならない期間を選択します。バーンレートが高いほど、長いウィンドウを小さくする必要があります (重大な問題をより早く発見できるように)。

アプローチ #2: 理論上のエラーバジェット消費量

あるいは、バーンレートと長いウィンドウの組み合わせを、理論上のエラーバジェット消費量で考えてもよいでしょう。

$$\text"バーンレート" = {\text"SLO 目標の長さ (時間単位) " * \text" エラーバジェット消費率"} / {\text"長いウィンドウ (時間単位) " * 100%}$$

例えば、7 日間の SLO の場合、1 時間を長いウィンドウとして、理論上のエラーバジェット消費量が 10% の場合にアラートを発するには、次のようなバーンレートを選択する必要があります。

$$\text"バーンレート" = {7 \text"日" * 24 \text"時間" * 10% \text"消費したエラーバジェット"} / {1 \text"時間" * 100%} = 16.8$$

注: メトリクスベースの SLO の場合、アプローチ #2 の関係は、長いウィンドウに含まれる発生回数の合計を、SLO 目標値の全長に外挿するものです。実際には、メトリクスベースの SLO によって追跡される発生回数の合計は、一日を通して異なる可能性が高いため、観測されるエラーバジェット消費量は、この関係に正確に対応しません。バーンレートアラートは、エラーバジェットの大幅な消費を発生前に予測するためのものです。モニターベースの SLO の場合、時間は常に一定の速度で移動するため、理論上のエラーバジェット消費量 と実際のエラーバジェット消費量は同じになります。例えば、60 分のモニターデータは、常に 1 時間のウィンドウに含まれます。

モニターの作成

1. SLO ステータスページに移動します。
2. 新しい SLO を作成、または既存のものを編集し、Save and Set Alert ボタンをクリックします。既存の SLO の場合は、SLO 詳細のサイドパネルの Set up Alerts ボタンをクリックすると、アラートのコンフィギュレーションに直接アクセスできます。
3. Step 1: Setting alerting conditions で Burn Rate タブを選択します。
4. 特定の長さのウィンドウで、特定のバーンレートが測定されたときに、アラートがトリガーされるように設定します。
   • バーンレートの値は、以下の範囲でなければなりません。 $$0 < \text"バーンレート" ≤ 1 / {1 - \text"SLO 目標"}$$
   • Datadog は、長いウィンドウの最大値として 48 時間をサポートしています。長いウィンドウは、1 hour <= long window <= 48 hours の範囲である必要があります。
   • 短いウィンドウは、UI 上で short window = 1/12 * long window として自動的に計算されます。
   • API または Terraform を使用して別の短いウィンドウ値を指定できますが、常に長いウィンドウより小さい値である必要があります。
5. Add Notification information into the Configure notifications and automations section.
6. SLO コンフィギュレーションページで Save and Exit ボタンをクリックします。

例

以下は、7 日、30 日、90 日の目標に対する Datadog の推奨値の表です。

• これらの例は 99.9% の目標値を想定していますが、96% という低い目標値でも妥当です (96% の最大バーンレートは 25)。しかし、より低い目標値を使用する場合は、最大バーンレート値のセクションで説明したように、より低い閾値が必要になる場合があります。Datadog では、消費される理論上のエラーバジェットの値を小さくするか長いウィンドウに大きな値を設定してアプローチ #2を使うことを推奨しています。
• メトリクスベースの SLO の場合、消費される理論上のエラーバジェットは、長いアラートウィンドウで観察された総発生数を SLO 目標値の全長に外挿することによって計算されます。

7 日間目標の場合:

30 日間目標の場合:

90 日間目標の場合:

推奨: バーンレートアラートが常に不安定であることがわかった場合、これは短いウィンドウを少し大きくする必要があることを示すものです。ただし、短いウィンドウを大きくすると、問題が終了した後のモニターの回復が遅くなることに注意してください。

API および Terraform

create-monitor API エンドポイントを使用して、SLO バーンレートアラートを作成することができます。以下は、過去 1 時間と過去 5 分に 14.4 のバーンレートが測定されたときにアラートを発するバーンレートアラートのクエリ例です。slo_id をバーンレートアラートを構成する SLO の英数字 ID に置き換え、time_window を 7d、30d、90d のいずれかに置き換えます (SLO の構成に使用する目標値によって異なります)。

burn_rate("slo_id").over("time_window").long_window("1h").short_window("5m") > 14.4

また、Terraform の datadog_monitor リソースを使用して SLO バーンレートアラートを作成することも可能です。以下は、上記と同じクエリ例を使用して、メトリクスベースの SLO にバーンレートアラートを構成する .tf の例です。

注: SLO バーンレートアラートは、Terraform プロバイダー v2.7.0 以前および v2.13.0 以降のみでサポートされています。v2.7.0 から v2.13.0 の間のバージョンはサポートされていません。

resource "datadog_monitor" "metric-based-slo" {
    name = "SLO Burn Rate Alert Example"
    type  = "slo alert"

    query = <<EOT
    burn_rate("slo_id").over("time_window").long_window("1h").short_window("5m") > 14.4
    EOT

    message = "Example monitor message"
    monitor_thresholds {
      critical = 14.4
    }
    tags = ["foo:bar", "baz"]
}