# Prometheusシリーズチャーン
## 定義
Prometheus において、時系列の識別子(ラベルセット)が短期間に大量に入れ替わる現象。新しいラベルセットが新しい時系列として登録される一方、旧時系列は「失活系列(stale series)」としてメモリ(HEAD)に残り続ける。Prometheus の通常 HEAD flush が 2 時間周期のため、その前に失活系列が累積してメモリ枯渇(OOM)を引き起こすリスクがある。
(Source: [[@2026__SREcon26Americas__Unlock High-Frequency Deployments without Blowing Up Prometheus]])
### 失活系列の発生源
- **ターゲット消滅**: プロセス停止・スケールダウン
- **計装変更**: ラベル追加・変更によって旧系列が別の系列として扱われる
- **Kubernetes ロールアウト**: Deployment では pod suffix が変わるため全系列が入れ替わる。StatefulSet では pod 名は同じでも IP 変更により instance ラベルが変わり、新系列として登録される
### Kubernetes 特有の増幅
```
my_metric{pod="my-pod-cf97d665c-wbzjs", ...} → my_metric{pod="my-pod-cf97d665c-vd5vf", ...}
```
pod 1 つあたり 100 メトリクスを持つとすると、再起動 1 回で Prometheus は 200 系列をメモリに保持することになる。高頻度デプロイでは 2 時間の flush より前に HEAD が圧迫される。
## 解決アプローチ
### stale-series compaction (Prometheus v3.10.0+)
閾値(`stale_series_compaction_threshold`)を設定し、失活系列比率がその値に達すると HEAD から失活系列をディスクの Block N へ先回りフラッシュする機能。
```yaml
storage:
tsdb:
stale_series_compaction_threshold: <0.0 to 1.0>
```
**トレードオフ**:
- ✅ メモリ削減・OOM 回避
- ❌ クエリ時に HEAD(メモリ) + Block N(ディスク)のマージが必要 → CPU 消費増・クエリレイテンシ増
- ❌ ルール数が多い環境ほどオーバーヘッドが大きい
**閾値選択指針** (Reddit 実験ベース):
計測: `prometheus_tsdb_head_stale_series{} / prometheus_tsdb_head_series{}`
| ピーク失活比率 | 推奨アクション |
|---|---|
| < 0.3 | 不要 |
| 0.3–0.5 | 様子見 |
| > 0.5 | 閾値を trial-and-error で決定 |
**注意**: この機能は「Prometheus を OOM から守る」保護目的。省メモリ目的には使わない。小規模 Prometheus や低チャーン環境ではオーバーヘッドが利点を上回る場合がある。
現状: **実験的(experimental)** / 既知バグ #18379 / 修正 ETA: Prometheus v3.12.0–v3.13.0
## 横断的知見
- 現時点では単一ソース([[@2026__SREcon26Americas__Unlock High-Frequency Deployments without Blowing Up Prometheus]])のみ。追加ソースで更新予定。
## 未解決の問い
- stale-series compaction のバグ #18379 の具体的な影響範囲は何か(どのようなクエリパターンで問題が顕在化するか)
- Prometheus v3.12.0–v3.13.0 でバグ修正後の本番推奨閾値のベストプラクティスは確立されたか
- VictoriaMetrics・Mimir などの互換システムはシリーズチャーン問題にどのようにアプローチしているか
- StatefulSet で instance ラベルを付けない設計(pod ラベルのみ)にすれば StatefulSet 系のチャーンを防げるが、そのトレードオフは何か
## 関連
- [[Prometheus]] / [[Prometheus TSDB]]
- [[@2026__SREcon26Americas__Unlock High-Frequency Deployments without Blowing Up Prometheus]]
- [[Ganesh Vernekar]] / [[Reddit]]
## 出典
- [[@2026__SREcon26Americas__Unlock High-Frequency Deployments without Blowing Up Prometheus]]: Ganesh Vernekar (Reddit), SREcon26 Americas 2026-03-26