Tech Learning Daily

アプリは「累計」しか教えない

Prometheus はプル型の監視システムで、設定した間隔（scrape_interval）ごとにアプリの /metrics を HTTP で取りに行き（スクレイプ）、その時点の値を時刻と一緒に保存する。保存された「時刻と値の列」を時系列と呼ぶ。

リクエスト数のような「起きた回数」はカウンタとして公開する。カウンタとは、増えることしかなく、プロセスの再起動時にだけ 0 に戻る累計値のことだ。現在のメモリ使用量のように上下する値はゲージと呼び、カウンタとは区別する。

直感的には「直近 1 秒のリクエスト数」をアプリが直接出す方が素直に思える。しかしそうすると、スクレイプが 1 回失敗しただけでその区間のリクエストは誰にも数えられずに消える。累計なら、次にスクレイプが成功したときの値に失敗区間の分も含まれているので、2 点の差を取れば何件起きたかは失われない。アプリ側は整数を 1 足すだけで済み、集計のコストを Prometheus 側に寄せられる点も累計方式の利点である。

rate() は「差 ÷ 時間」に 2 つの補正を足したもの

rate(http_requests_total[5m]) は、直近 5 分の窓に入ったサンプルから 1 秒あたりの平均増加量を返す。基本は「最後の値 − 最初の値」を経過秒数で割る計算だが、2 つの補正が入る。

1 つ目はカウンタリセットの補正だ。公式ドキュメントは、ターゲットの再起動などによる単調性の崩れを自動で補正すると明記している。値が前より小さくなったら「0 に戻ってからまた数え始めた」とみなし、戻る前の値を足し込む。たとえば 1000 → 1030 → 5 → 35 と並んだら、増加量は 30 + 5 + 30 = 65 と数える。

値
1030 ┤   ●
1000 ┤ ●  │ 再起動で 0 に戻る
     │    │
  35 ┤    │      ●
   5 ┤    └─●
     └─┬──┬──┬───┬──▶ 時刻
増加:   +30 +5  +30   = 65

2 つ目は外挿である。窓の端ちょうどにサンプルがあるとは限らないので、rate() と increase() は窓の両端まで傾きを延ばして推定する。このため increase(...[5m]) は「5 分間に何件増えたか」を返すのに、結果が 29.97 のような小数になることがある。壊れているのではなく、推定値として設計どおりの挙動だ。

窓の幅には目安がある。窓に 2 点以上のサンプルが入らないと差が取れず、結果が空になる。Grafana は窓をスクレイプ間隔の 4 倍以上にすることを勧めており、そのための変数 $__rate_interval を用意している。窓を広げるほど線はなめらかになるが、短いスパイクはならされて見えなくなる。直近 2 点だけで計算する irate() は逆に鋭く反応するが揺れが大きく、アラート条件には向かない。

histogram は「何秒以下が何件」の累積カウンタ

レイテンシの p99 を出すには、1 件ずつの所要時間を全部保存すれば確実だ。しかしリクエストのたびに値を保存すると、データ量はトラフィックに比例して増えていく。そこで histogram は、あらかじめ決めた境界値ごとに「この秒数以下だった件数」をカウンタで数える。境界値ごとの数え箱をバケットと呼び、ラベル le（less than or equal、以下）で境界を表す。

 0     0.1     0.25     0.5     1 (秒)
 ├──────┼───────┼────────┼──────┤
 │ 50件 │ 40件  │  8件   │ 2件  │
 └──────┴───────┴────────┴──────┘
 le="0.1"  =  50
 le="0.25" =  90 (50+40)
 le="0.5"  =  98 (90+8)
 le="1"    = 100
 le="+Inf" = 100 = _count

各バケットは自分の境界以下の全件を数える累積値なので、le="+Inf" は全件数と一致し、これが _count になる。合計時間の _sum も一緒に公開されるので、rate(_sum[5m]) / rate(_count[5m]) で平均レイテンシも出せる。どれもただのカウンタなので、前節の rate() がそのまま使える。

境界はアプリ側で決める。Go のクライアントライブラリの既定値 DefBuckets は .005, .01, .025, .05, .1, .25, .5, 1, 2.5, 5, 10（秒）で、ドキュメント自身が「たいていは用途に合わせて定義し直す必要がある」と書いている。境界は時系列の数そのものなので、増やせば精度は上がるが、ラベルの組み合わせ × バケット数だけ保存量が増える。

p99 は「バケットの中を均等とみなした」推定値

histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) は、上の図から p95 を次のように求める。100 件中 95 番目の観測は、90 件目まで（0.25 秒以下）と 98 件目まで（0.5 秒以下）の間、つまり 0.25〜0.5 秒のバケットにある。このバケットの 8 件の中では 5 番目なので、公式ドキュメントのとおりバケット内の観測が一様に分布していると仮定し、0.25 + 0.25 × 5/8 ≒ 0.406 秒と答える。

ここに落とし穴がある。実際の 8 件が全部 0.26 秒付近に固まっていても、計算結果は 0.406 秒のままだ。誤差の大きさはその分位数が入ったバケットの幅で決まる。公式の解説には、本当の p95 が約 220ms なのに 200〜300ms のバケットに入ったせいで 295ms と出て、300ms の SLO をほぼ破っているように見えた例が載っている。また分位数が最上位の +Inf バケットに入ると、2 番目に高いバケットの上限がそのまま返る。上の例で境界の最大が 1 秒なら、本当は 8 秒かかっていても p99 は 1 秒と表示される。

だからバケットの境界は SLO の閾値に合わせて置く。「300ms 以内に 95%」を見たいなら le="0.3" を作れば、rate(..._bucket{le="0.3"}[5m]) / rate(..._count[5m]) で「300ms 以内に返せた割合」を補間なしで正確に計算できる。分位数を推定するより、閾値以下の割合を見る方が histogram の得意な使い方だ。

// Go: SLO 300ms の前後を細かく区切る
prometheus.NewHistogram(prometheus.HistogramOpts{
  Name:    "http_request_duration_seconds",
  Buckets: []float64{.05, .1, .2, .3, .45, .6, 1, 2.5},
})

集計は rate() が先、sum が後

Pod が 10 個あれば、バケットの時系列も 10 組ある。全体の p99 は、まずインスタンスごとに rate() を取り、le ラベルを残したまま足し合わせてから histogram_quantile() に渡す。

histogram_quantile(0.99,
  sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

順番を逆にして先に sum すると壊れる。1 つの Pod が再起動してそのカウンタが 0 に戻ると、合計値ががくんと下がる。rate() はこれを合計全体のリセットと誤認するため、存在しない急増がグラフに現れる。公式ドキュメントが「必ず先に rate()、それから集計」と書いているのはこのためだ。by (le) を付け忘れて le を消してしまうと、どのバケットの値か分からなくなり分位数は計算できない。

似た型に summary があり、こちらはアプリ側で p99 などの分位数そのものを計算して公開する。精度は高いが、分位数は平均できない。Pod A の p99 が 0.1 秒、Pod B が 0.9 秒でも、全体の p99 は 0.5 秒とは限らず、リクエスト数の偏り次第で大きく変わる。公式の解説も summary の分位数の avg() を「統計的に無意味」として誤りの例に挙げている。複数インスタンスで動く Web アプリでは、足し算で合算できる histogram を選ぶのが基本になる。なお最近の Prometheus には、境界を事前に決めなくてよく誤差も小さい native histogram があり、公式はクライアントが対応していればこちらを推奨している。