# Unlock High-Frequency Deployments without Blowing Up Prometheus Navigation: [[@2026__SREcon26Americas__Unlock High-Frequency Deployments without Blowing Up Prometheus]] | [[Prometheus]] | [[Prometheusシリーズチャーン]] **登壇者**: [[Ganesh Vernekar]]（Staff Software Engineer / [[Reddit]]、Prometheus TSDB メンテナー） **会議**: SREcon26 Americas / Seattle WA / 2026-03-26 13:55–14:15 **スライド**: 35 ページ / 動画: [YouTube qUvom_WiKc4](https://www.youtube.com/watch?v=qUvom_WiKc4) --- ## 概要 Kubernetes 上の高頻度デプロイは Prometheus に隠れたボトルネックを引き起こす。Pod の入れ替わりのたびにメトリクスのラベルセットが変わり、古い時系列は「失活系列(stale series)」としてメモリに居座る。Prometheus の通常 HEAD flush は 2 時間ごとのため、その前に OOM クラッシュが起きやすい。本トークは Prometheus v3.10.0 で実験的に導入された **stale-series compaction** の設計・Reddit 本番実験結果・閾値選択指針をまとめる。 ## 主要メッセージ - 高頻度デプロイが Kubernetes シリーズチャーンを起こし Prometheus の HEAD メモリを枯渇させる仕組みを図解で説明する（p.10–16） - `stale_series_compaction_threshold` を設定すると、失活系列比率がその値に達した時点でディスクへの先回りフラッシュが走る（p.24–25） - この機能はメモリを下げる代わりに CPU 消費とクエリマージオーバーヘッドを増加させる。「保護」用途に限定すべき（p.28–30） - 失活系列比率 > 0.5 が目安。Reddit 本番では 0.4–0.7 で推移したため閾値 0.4 を採用（p.31–32） - 現時点では既知バグ #18379 があり本番導入は非推奨。修正 ETA は v3.12.0–v3.13.0（p.26, p.34） ## 視覚的に重要な図表 **p.4 Prometheus アーキテクチャ概要** ![[_attachments/2026__SREcon26Americas__Unlock-High-Frequency-Deployments-without-Blowing-Up-Prometheus/page-004.png]] ターゲット→Prometheus(TSDB)→Alertmanager/Grafana の pull-based 3 層構成を示す。TSDB が内蔵されている点が本トークの焦点。 **p.12–16 失活系列の可視化アニメーション(代表: p.16)** ![[_attachments/2026__SREcon26Americas__Unlock-High-Frequency-Deployments-without-Blowing-Up-Prometheus/page-016.png]] 各色ブロックが個別時系列を表す。Head(RAM)上で赤×印のついた失活系列が増え続け、ディスクへフラッシュされないまま HEAD を圧迫する様子を示す。 **p.17 本番障害例(3 チャートダッシュボード)** ![[_attachments/2026__SREcon26Americas__Unlock-High-Frequency-Deployments-without-Blowing-Up-Prometheus/page-017.png]] 上: メモリ使用率(正規化)がデプロイ波に合わせてステップ状に上昇し最終的に 100% へ到達。左下: 失活系列比率が各デプロイで急騰。右下: total(青) vs stale(橙)の推移。 **p.21 本番障害例(フェーズ解説)** ![[_attachments/2026__SREcon26Americas__Unlock-High-Frequency-Deployments-without-Blowing-Up-Prometheus/page-021.png]] 4 フェーズをアノテーションで解説。最終的に total series と stale series のギャップが「active series だけ」に相当し、active 数は変わらないのに OOM が起きる仕組みを示す。 **p.24 stale-series compaction: フラッシュの瞬間** ![[_attachments/2026__SREcon26Americas__Unlock-High-Frequency-Deployments-without-Blowing-Up-Prometheus/page-024.png]] 失活系列(×印付き)が HEAD から切り離され、ディスクの Block N へと向かう矢印が示される。 **p.25 stale-series compaction: 完了後状態** ![[_attachments/2026__SREcon26Americas__Unlock-High-Frequency-Deployments-without-Blowing-Up-Prometheus/page-025.png]] HEAD には active series のみが残り、Block N にはコンパクトされた失活系列が収まっている。HEAD のメモリ使用量が大幅に減少した状態。 **p.26 設定方法** ![[_attachments/2026__SREcon26Americas__Unlock-High-Frequency-Deployments-without-Blowing-Up-Prometheus/page-026.png]] ```yaml storage: tsdb: stale_series_compaction_threshold: <0.0 to 1.0> ``` Prometheus v3.10.0 以降対応。**Experimental** 機能 / 既知バグ [#18379](https://github.com/prometheus/prometheus/issues/18379) あり。 **p.27 本番実験結果(新 vs 旧の比較)** ![[_attachments/2026__SREcon26Americas__Unlock-High-Frequency-Deployments-without-Blowing-Up-Prometheus/page-027.png]] new(compaction 有効) vs old の 4 チャート比較。メモリ使用率が削減され、失活系列比率も低く安定している。Memory Percentage Change グラフで緑(削減)領域が明確に現れる。 **p.28 コスト: "It's not free"** ![[_attachments/2026__SREcon26Americas__Unlock-High-Frequency-Deployments-without-Blowing-Up-Prometheus/page-028.png]] CPU Usage (Normalized) と CPU Percentage Change の 2 チャート。コンパクション発動時に CPU が増加するサイクルがピンク領域として現れる。ルール数が多いほど影響大。 **p.29–30 クエリ経路の変化(Before/After)** ![[_attachments/2026__SREcon26Americas__Unlock-High-Frequency-Deployments-without-Blowing-Up-Prometheus/page-029.png]] Before: TSDB querier → HEAD(メモリ)を単純イテレーション。All in-memory で高速。 ![[_attachments/2026__SREcon26Americas__Unlock-High-Frequency-Deployments-without-Blowing-Up-Prometheus/page-030.png]] After: TSDB querier が HEAD(メモリ) + Block N(ディスク)の両方をロードし、**マージオーバーヘッド**が発生。PromQL エンジンへの負荷が増加する。 **p.31 閾値選択ガイド** ![[_attachments/2026__SREcon26Americas__Unlock-High-Frequency-Deployments-without-Blowing-Up-Prometheus/page-031.png]] 計測用 PromQL(v3.6.0+): `prometheus_tsdb_head_stale_series{} / prometheus_tsdb_head_series{}` | 失活系列比率のピーク | 推奨アクション | |---|---| | < 0.3 | 不要。気にしない | | 0.3–0.5 | 潜在的問題に注意して様子見 | | > 0.5 | 閾値を選んで試行錯誤（「あまり頻繁に触れず、かつ稀にも触れない値」） | 前提: 高チャーンが実際に大規模 Prometheus を壊している場合のみ検討。 **p.32 Reddit 本番の失活系列比率(1 週間推移)** ![[_attachments/2026__SREcon26Americas__Unlock-High-Frequency-Deployments-without-Blowing-Up-Prometheus/page-032.png]] 2/10–2/17 の stale series ratio 推移。0.1–0.8 の広い範囲で変動し、多くの時間帯で 0.3–0.5 を超えている。閾値 0.4 を採用した根拠となるデータ。 **p.33 誤設定時の弊害** ![[_attachments/2026__SREcon26Americas__Unlock-High-Frequency-Deployments-without-Blowing-Up-Prometheus/page-033.png]] 閾値を低く設定しすぎると compaction が頻発し、メモリ・CPU ともにオーバーヘッドが増加。orange(旧)vs blue(新)でほぼ同等かむしろ悪化するケース。 ## 口頭説明・補足 transcript より: - 「失活系列が増えているのは、active series の数は変わらないのに比率だけが下がっていくことで分かる。変わっているのは分母ではなく分子だ」 - 「stale series compaction は Prometheus を『保護』するためのもの。メモリを節約するためのものではない。CPU コストとのトレードオフが明確にあるため、吹き飛ぶ直前の大型 Prometheus にだけ使え」 - 「閾値は試行錯誤が必要。ルールの量、クエリ負荷、Prometheus のサイズによって最適値が変わる」 - 「Reddit では失活系列比率が常に 0.4 以上、多くの時間は 0.6–0.7 だったため、判断として 0.4 に設定した」 ## Q&A transcript に Q&A セクションの字幕は含まれていない（「time over」で終了）。 ## 概念・実体への接続 - [[Ganesh Vernekar]]（登壇者） - [[Reddit]]（所属組織・事例元） - [[Prometheus]]（対象システム） - [[Prometheus TSDB]]（内部ストレージエンジン） - [[Prometheusシリーズチャーン]]（中心概念） ## 限界・不確実点 - transcript は YouTube 自動字幕(機械精度)のため固有名詞・数値の読み違えがある可能性がある - p.27–28 のグラフ軸値(具体的なメモリ削減%)は正規化されており絶対値不明 - p.32 の日付は 02/10–02/17 だが年次不明(2026 年初と推定) - バグ #18379 の修正済み状況は発表時点(2026-03-26)での情報。v3.12.0-v3.13.0 は ETA 予定