- ブラウザURL入力
- DNS名前→IP
- ルータ経路選択
- ロードバランサ振り分け
- Nginx受け口今ここ
- アプリ処理今ここ
- DB保存
SLI の値は測りますが、何を数えるかは決めます。今回は、比をどの長さの窓で数えるかを決め、短い窓の比を予算の消費速度として読みます。
まず結論
同じ5分間・180件の失敗でも、5分の窓で数えればバーンレートは 20.0、1時間の窓なら 1.67 です(窓の長さぶんの記録がある場合)。窓の長さを決めることは、分母の件数を決めることです。
記録が窓に満たなければ、長い窓どうし(1h と 6h)は同じ値になり、短い窓に近い値になります。件数が少なければ1件で比が跳ね、0件の窓では比が NaN になるか、結果から消えます。
数時間前から毎秒30件を処理しているサービスで、5分間だけ要求の2%が 500 になりました(SLO 99.9%)。失敗が終わった時点の、5分窓と1時間窓のバーンレートはどうなるでしょうか。
当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。
この回で決めること — 比をどの長さの窓で数えるか
SLO は期間全体(たとえば30日)の比で判定しますが、異常に早く気づくには直近の短い集計の窓でも比を取ります。窓の比の分子も分母も、その窓の中の件数です。窓の長さを決めると分母が決まる——この回で決めるのはこれです。
窓の比が SLO を上回っても、SLO 違反ではありません。違反は期間全体の比で決まります。そこで窓の比を「予算を燃やす速さ」に直して読みます。SRE Workbook 第5章(2018)の定義です。
Burn rate is how fast, relative to the SLO, the service consumes the error budget.
続けて a constant 0.1% error rate uses exactly all of the error budget: a burn rate of 1.(SLO 99.9%・30日)と書き、対応を表にしています。
Burn rate Error rate for a 99.9% SLO Time to exhaustion 検算1 0.1% 30 days 720h2 0.2% 15 days 360h10 1% 3 days 72h1,000 100% 43 minutes 0.72h = 43.2分
どの行も、エラー率を 0.1%(= 1 − 0.999)で割るとバーンレートになります。本教材はこれを バーンレート = 窓のエラー率 ÷ (1 − SLO) と整理します。Workbook がこの形の式を書いているのではなく、定義文と表から導いた整理です。
- ・どの窓も、窓の長さぶんの記録がある場合の値
- ・分子は3つとも同じ180件
満ちた窓と、満ちていない窓で同じ失敗を数える
Prometheus v3.15.0(prom/prometheus:v3.15.0、Docker 28.4.0 linux/arm64)に、Workbook の記録ルール job:slo_errors_per_request:ratio_rate10m と同じ形のルールを(記録ルールは、式を一定間隔で評価して結果を新しい時系列として保存する設定)窓 5m・1h・6h で置きました。
- record: svc:slo_errors_per_request:ratio_rate5mexpr: sum by (svc) (rate(http_requests_total{code=~"5.."}[5m])) / sum by (svc) (rate(http_requests_total[5m]))- record: svc:slo_burn_rate:rate5mexpr: svc:slo_errors_per_request:ratio_rate5m / (1 - 0.999)
まず満ちた窓。1時間を実時間で待てないので、15秒刻みのカウンタ値を7時間ぶん作って Prometheus 付属の道具 promtool で投入し(値は模擬)、計算は Prometheus 本体に問い合わせました。2回走らせ、出力はバイト単位で一致しました。
# T0+3h05m(失敗が終わった時刻)increase 5m 全件 / 5xx 9000 / 180比 5m(直接クエリ) 0.02burn 1h(直接クエリ) 1.6666782892488774警報 14.4x(1h AND 5m) []# T0+6hburn 6h(記録ルール) 0.277970813064628
5m の比 0.02 はバーンレート 20、1h は 1.67。Workbook の呼び出し条件(1h と 5m の両方が 14.4 倍超)は鳴りません。
次に満ちていない窓。同じ筋書きを、Prometheus がアプリの計測値を5秒ごとに取りに行く実際のスクレイプで、起動直後から流しました。アプリは python:3.12-slim の自前実装、負荷は目標30件に届かず約23.5件/秒、起動120〜420秒に50件に1件を 500 にしました。
svc:slo_burn_rate:rate5m 19.916293837494567svc:slo_burn_rate:rate1h 14.43984856268113svc:slo_errors_per_request:ratio_rate6h 0.014439848562681141警報 14.4x(1h AND 5m) busy-init=0.014439848562681143
1h のバーンレートは 14.44、6h の比も 1h と同じ 0.01444 で、呼び出しが鳴りました。1h 窓に入っている要求は起動後7分ぶん(失敗141件、カウンタの合計で9,962件)だけで、満ちた窓なら入る残り53分ぶんの成功が分母にありません。記録の無い区間は要求0件と同じ扱いですが、分子も0件なので比は変わりません。5m(0.0199)より約27.5%低いのは、1h 窓には失敗が始まる前の健全な2分間も入るからです。同じ実行の別サービスは 14.367 で外れ、2回目の実行では両方鳴りました。閾値のすぐ近くで揺れています。
「1h は約1.7倍」は、1時間ぶんの記録がある窓に限った話です。 起動直後や新しいサービスでは、長い窓は満ちるまで、短い窓に近い値しか出しません。
記録の揃った5分窓で、バーンレートが 20 と出ました(SLO 99.9%、期間30日)。読み方として適切なのはどれですか。
件数の少ない窓では、1件が比を決める
窓の比は、窓の中の件数が少ないと意味を変えます。Workbook の Low-Traffic Services の節です。
if a system receives 10 requests per hour, then a single failed request results in an hourly error rate of 10%. For a 99.9% SLO, this request constitutes a 1,000x burn rate and would page immediately, as it consumed 13.9% of the 30-day error budget.
表の対応で計算すると 10% ÷ 0.1% = 100 です。同じ文の 13.9% も 100 と合います。Workbook が数式で示す「発火時点の予算消費 = バーンレート × 窓の長さ ÷ 期間」に入れると、100 × 1時間 ÷ 720時間 = 13.9%。1,000 なら 139% です。続く seven failed requests in 30 days も 7,200件 × 0.001 = 7.2件で合います。Web 版(2026-09-28 取得)の本文は 1,000x と書いており、表とも計算とも食い違います。正誤表の有無は確認できていません。
件数がさらに減って0件の窓では、比は 0 ÷ 0 です。Prometheus の二項演算は the usual IEEE 754 floating point arithmetic, including the handling of special values like NaN に従い、値は NaN になります。一方、片方の系列そのものが無ければ series for which no matching entry in the opposite vector can be found are not part of the result、つまり行ごと消えます。
窓の状態 比の出方系列あり・要求0件 NaN(値として出る)系列なし・要求も無い 結果に現れない要求あり・失敗0・5xx の系列なし 結果に現れない(健全なのに比が無い)
3つ目が最も見落とされます。公式文書は export a default value such as 0 for any time series you know may exist in advance と勧め、ラベルの無いメトリクスは多くのクライアントが自動で0を出すと書きます。しかし code ラベル付きの 5xx は、自分で0を出さない限り最初の失敗まで存在しません。
0件の窓を出力で見る
同じライブ実験の、まだ1件も失敗していない起動91秒後です。4つのアプリは負荷の有無と、500 を0で先に出すかどうかだけが違います。
http_requests_totalbusy-noinit 200=2054(500 の系列なし)busy-init 200=2084 500=0idle-init 200=0 500=0(idle-noinit は系列なし)svc:slo_errors_per_request:ratio_rate5m idle-init=NaN busy-init=0count(svc:slo_errors_per_request:ratio_rate5m) 2
比が出たのは4つのうち2つ。busy-noinit は2,054件を処理して失敗0なのに、比がありません。画面では「データなし」になり、100% とも 0% とも読めません。
件数の少ない窓も見ます。模擬カウンタで毎時10件(6分に1件)、1件だけ 500 にしたサービスです。
increase 1h code=200: 9.03765690376569 code=500: 1比 1h(直接) 0.0996248436848687比 5m(記録) NaN
1h 窓はバーンレート 99.6、5m 窓は要求が無く NaN。5m 窓は問い合わせた7時刻で 0 が2回、NaN が5回と入れ替わりました。increase() の 9.04 は外挿によるもので、文書は it is possible to get a non-integer result even if a counter increases only by integer increments と書きます。
失敗が一度も無い健全なサービスについて、5xx の比の記録ルールが結果に1行も出ません。最も考えられる原因はどれですか。
流量の多いサービスの5分窓
毎秒30件なら5分窓に9,000件。180件の失敗で比は2%、バーンレート20。失敗が1件増えても比は約0.011ポイントしか動きません。
要求 失敗 比 burn9,000 180 0.02 209,000 181 0.0201 20.1
毎時10件のサービスの1時間窓
1件の失敗で比は10%、バーンレート100、30日の予算の13.9%。同じサービスの5分窓には要求が0件か1件しか入らず、0件の時刻は NaN です。
窓 要求 失敗 比 burn1h 10 1 0.1 1005m 0 0 NaN NaN
2つとも同じ記録ルールで数えています。値の意味を変えているのは何でしょうか。
窓の中に何件あるかを、両方で数えてみてください。
この章のまとめ
- 窓の長さを決めることは、分母の件数を決めること。 同じ180件の失敗が 5m で 20、1h で 1.67、6h で 0.28。
- バーンレートは Workbook の定義文と Table 5-4 から「窓のエラー率 ÷ (1 − SLO)」と整理できる。窓の比は SLO 違反を意味しない。
- 満ちていない窓では 1h と 6h が同じ値になり 5m に近づく(実機で 5m 19.9・1h 14.4、6h の比は 1h と同じ)。14.4x の呼び出しが鳴った。
- 毎時10件・1件失敗は計算でバーンレート 100(予算の13.9%)。Workbook 本文の 1,000x とは食い違う。
- 0件の窓は NaN / 系列なし / 健全なのに比なし の3通り。3つ目は 5xx を0で先に出せば 0 になる。
自分の現場で確かめる
読んだだけでは身につきません。手元の環境で実際に見てみてください。
理解度チェック
読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。
Workbook 第5章の低トラフィックの例(毎時10件・1件失敗・SLO 99.9%)について、正しいのはどれですか。
用語集(4語)
- バーンレート
- SLO に対して予算を消費する速さ。1 なら期間の終わりにちょうど尽きる。本教材では Workbook の定義文と Table 5-4 から「窓のエラー率 ÷ (1 − SLO)」と整理する。
- 集計の窓
- 比を数える直近の時間幅(5m・1h・6h など)。SLO の期間とは別。窓の長さが分母の件数を決める。
- 満ちていない窓
- 起動直後などで、窓の長さぶんの記録が無い状態。実機では 1h・6h の比が同じ値になり、5m に近づいた(5m 19.9・1h 14.4、6h の比は 1h と同じ)。
- NaN
- 0 ÷ 0 などの結果。Prometheus の二項演算は IEEE 754 に従う。比の表に NaN として出るが、閾値との比較では真にならない。
出典(一次ソース)
- SRE Workbook — Chapter 5. Alerting on SLOs(© 2018 Google。Burn rate の定義・Table 5-4・Table 5-6・式・Low-Traffic Services。Web 版 2026-09-28 取得) ↗
- Prometheus — Query functions(rate()・increase() の外挿。latest を 2026-09-28 取得、頁に版表記なし。実機は v3.15.0) ↗
- Prometheus — Operators(IEEE 754・対になる系列が無い場合。latest を 2026-09-28 取得) ↗
- Prometheus — Instrumentation(Avoid missing metrics。2026-09-28 取得) ↗
- Prometheus — Recording rules(2026-09-28 取得) ↗