- ブラウザURL入力
- DNS名前→IP
- ルータ経路選択
- ロードバランサ振り分け
- Nginx受け口
- アプリ処理今ここ
- DB保存今ここ
第13期の最終回です。9本で見てきたことを「壊れる前に何を残しておくか」の一点にまとめます。
まず結論
事故のあとに見えるのは、事故の前に残すと決めた数字だけです。Prometheus 公式は summary について you cannot "recalculate" the quantiles later と書きます。
だから何を残すかは、答えたい問いから逆算する判断です。閾値もまた判断で、測った値ではありません。SRE Book は 100 ミリ秒という例を自ら obviously an arbitrary value と呼びます。
1分ごとの平均だけを1年ぶん保存してきました。いま「先週の火曜の p99 は何ミリ秒か」と聞かれています。答えられますか。
当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。
測定は、事故のあとには始められない
障害の最中に見えるのは、事故の前に誰かが残すと決めた数字だけです。決めていなかった数字は、どれだけ急いでも取れません。
これを直接に書くのが Prometheus 公式ドキュメント(2026-09-18 取得)です。計装した側が決めた分位数を計算して出す summary について、こうあります。
you cannot "recalculate" the quantiles later if you desire another time window or another percentile
制約は2段です。同じ文は続けて you cannot aggregate quantiles とも書きます。複製ワーカーが出した分位数を足し合わせて全体の値にすることもできません。
原理は1つ。残していない細かさは、後からは作れない。
- ・OpenTelemetry 仕様の再集約は「高頻度→長い間隔」「属性を減らす」の向きだけ
- ・仕様は逆を禁止していない。一方向を列挙しているだけで、戻せないのは本教材の帰結
バケットの境界は、計装のときに固定される
Prometheus の classic histogram は、値の範囲ごとに件数を数えて残します。区切り方について公式はこう書きます。
If you instrument code with classic histograms, you will configure fixed bucket boundaries.
続けて picking the right buckets in advance can be challenging. And changing buckets later creates a lot of disruption とあります。境界は事前に決める必要があり、後で変えると断絶が生じます。
境界の粗さは、そのまま答えの粗さです。公式の例では、要求がほぼ 220 ミリ秒に集まるとき、classic histogram の 200〜300 ミリ秒のバケット({le="0.3"})から histogram_quantile は95パーセンタイルを 295 ミリ秒と推定します。保証されるのは 200〜300 の間ということだけです。細かい native histogram(バケット約 0.210〜0.229)なら推定は 228 ミリ秒でした。同じ文書はこうも書きます。
Quantiles, whether calculated by the instrumented binary or on the Prometheus server, are estimated.
前回、実行計画の行数は推定であって実測ではないと見ました。p99 も推定です。
「後から計算し直せるように、とにかく全部を最も細かく残す」という方針の問題は何ですか。
何を残すかは、答えたい問いから逆算する
では全部を最も細かく残せばよいかというと、本コース3本目と矛盾します。SRE Book 第6章も、分解能の選び方を費用の側から書きます。
Collecting per-second measurements of CPU load might yield interesting data, but such frequent measurements may be very expensive to collect, store, and analyze.
同じ節は、粗すぎる場合の損も並べます。
Observing CPU load over the time span of a minute won't reveal even quite long-lived spikes that drive high tail latencies.
写っていないことは起きていない証拠ではないという5本目の話が、「取り逃すことを設計の時点で決めてしまう」形で現れます。
つまり細かさの選択は、費用と見落としの取引です。基準になるのは事故のあとに答えたい問いしかありません。
SRE Book が挙げる出発点は4つです。
The four golden signals of monitoring are latency, traffic, errors, and saturation. If you can only measure four metrics of your user-facing system, focus on these four.
これは書籍の提唱であって規格ではありません。図解コース「USEメソッド」の USE 法を Gregg の手法として読むのと同じ扱いです。latency については成功した要求と失敗した要求の遅延を区別せよとあり、a slow error is even worse than a fast error! と続きます。errors も、明示的な500番台に加えて、an HTTP 200 success response, but coupled with the wrong content のような暗黙のものと、方針として決めた「1秒超は誤り」を含みます。
閾値は、測った値ではない
その errors の3つ目、「1秒超は誤りと決める」に目を留めてください。1秒という値は、どこからも測れません。 決めるものです。
SRE Book 第4章は、測る側と決める側を言葉で分けます。SLI は a carefully defined quantitative measure、定量的な尺度です。SLO は a target value or range of values、目標値または目標範囲です。そして平均応答時間を 100 ミリ秒未満にという例の直後に、こう括弧書きします。
100 milliseconds is obviously an arbitrary value
出典自身が「明らかに恣意的な値」と認めています。閾値というものが現象の側にはないのです。同書はさらに、外から来る要求の毎秒問い合わせ数は利用者の都合で決まるとして you can't really set an SLO for that とも書きます。
ここから読み方が決まります。「閾値を超えました」は現象の報告ではなく、引いた線を越えたという報告です。線が動けば同じ現象が異常にも正常にもなります。だから最初の問いは「何が起きたか」ではなく「この線は誰が、何を根拠に引いたか」です。
要素 出どころ 変えられるか観測した値 測定器の出力 測り方次第で変わる比べる線 人が決めた目標 いつでも決め直せる異常の判定 上の2つの比較 線を動かせば結果も動く
SRE Book は決め直しについても、It's better to start with a loose target that you tighten than to choose an overly strict target that has to be relaxed と書きます。線は動かしてよいという前提が、線が測定値ではないことを示しています。
「応答が 100 ミリ秒を超えたら異常とする」という取り決めの説明として、最も正確なのはどれですか。
ヒストグラムのバケット境界
計装の時点で値の区切りを決め、以後はその区切りごとの件数だけが残ります。区切りより細かい問いには答えられません。
残した形 答えられる問い 答えられない問い平均と件数 合計・1件の費用 分布の裾バケット件数 区切り幅の分位数 区切りより細かい値決め打ち分位数 その分位数だけ 別の分位数・合算
SLO として置く目標値
どこから先を問題と呼ぶかを人が決め、以後の警報はその線との比較として出ます。SRE Book は例示した 100 ミリ秒を自ら arbitrary と呼びます。
見えている文言 実際に含まれるもの応答が遅延 測った値 + 人が引いた線正常に戻った 測った値 + 同じ線異常なし 線を越えていないだけ
バケットの境界と、SLO の目標値。片方は計装の設定、片方は運用の取り決めで、決める人も違います。共通する構造は何でしょうか。
「その数字を後から変えたとき、過去のデータはどうなるか」を両方で考えてみてください。
この章のまとめ
- 残していない細かさは後から作れない。Prometheus 公式は summary について you cannot "recalculate" the quantiles later と書き、分位数は合算もできないとしている。
- OpenTelemetry 仕様の再集約は「高頻度→長い間隔」の一方向。仕様は逆を禁止しておらず、戻せないは本教材の帰結。
- 「全部を最も細かく残す」は3本目と矛盾する。細かさは答えたい問いから逆算して選ぶ。
- 閾値は判断であって測った値ではない。SRE Book は 100 ミリ秒の例を自ら obviously an arbitrary value と呼ぶ。
- 4つのゴールデンシグナルは書籍の提唱で規格ではない。誰の提唱かを添えて読む。
- 9本を1文にすると、その数字はどの問いに答え、誰が何を先に決めたのかを確かめること。事故を防ぐ手立てではなく、切り分けられる状態にする手立て。
自分の現場で確かめる
読んだだけでは身につきません。手元の環境で実際に見てみてください。
理解度チェック
読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。
Prometheus 公式が summary について述べている制約は、どれですか。
用語集(5語)
- 分解能(粒度)
- どれくらい細かく測り、残すか。SRE Book は毎分の CPU 負荷では長めのスパイクも写らないと書く一方、毎秒の収集は費用が高いとも書く。
- ヒストグラムのバケット
- 値の範囲ごとに件数を数えて残す形式。境界は計装の時点で固定する。Prometheus 公式は、適切な境界を事前に選ぶのは難しく、後から変えると大きな断絶が生じると書く。
- SLI
- service level indicator。SRE Book 第4章では、提供する水準の一面を注意深く定義した定量的な尺度。測る対象の側。
- SLO
- service level objective。SLI で測られる水準に対する目標値または目標範囲。決める側。SRE Book は例示した 100 ミリ秒を自ら arbitrary と呼ぶ。
- 再集約
- 集めた測定値をまとめ直すこと。OpenTelemetry の Metrics Data Model は、高頻度を長い間隔へまとめる変換と、属性を減らす変換を挙げる。