Prometheusのストレージは「砂時計」ではない：TSDBを支配し、運用コストを最適化する極意
Prometheusの運用において、最も恐ろしいのは「朝起きたらディスクが100%で、メトリクスが全消滅していた」という悪夢だ。
多くのエンジニアは、とりあえず `retention.time` を設定して安心している。だが、それは時限爆弾を抱えているのと同じだ。今日は、PrometheusのTSDB（Time Series Database）の深淵を覗き込み、単なる「監視ツール」を「盤石なオブザーバビリティ基盤」へと昇華させるための技術論を伝授する。
—
1. TSDBの解剖：データは「ブロック」として生きている
Prometheusのローカルストレージは、単純なログファイルではない。TSDBと呼ばれる、高効率な時系列データ構造だ。
- Head Block: 現在書き込み中のメモリ上のデータ（WAL: Write Ahead Logとしてディスクにも同期される）。
- Persistent Blocks: 2時間ごとにメモリからディスクへフラッシュされる、圧縮された読み取り専用のブロック。
極限の知見:
Prometheusのディスク消費量は「保存期間」だけでなく、「アクティブな時系列数（Cardinality）」に支配される。いくら保持期間を短くしても、高カーディナリティ（例：URLごとにラベルを生成するような設計）を許せば、ディスクは一瞬で飽和する。まずは「メトリクスの断捨離」こそが、ストレージ防衛の第一歩だ。
—
2. 精緻な見積もり：勘に頼らない計算式
ストレージ不足を事前に防ぐには、以下の計算式で「平均ディスク消費量」を弾き出すのがプロの仕事だ。
$$ \text{Total Storage} \approx (\text{Samples per second} \times \text{Bytes per sample}) \times \text{Retention Time} $$
- Samples per second: `rate(prometheus_tsdb_head_samples_appended_total[1h])` で確認せよ。
- Bytes per sample: Prometheusの標準的な圧縮アルゴリズム（Gorilla）により、1サンプルあたり平均 1.5〜2.5バイト 程度に収まるのが一般的だ。
現場のTips:
`prometheus_tsdb_blocks_bytes_total` メトリクスをPromQLで可視化し、増加トレンドを線形回帰で予測するダッシュボードを必ず作っておけ。
—
3. 設定のベストプラクティス：YAMLの作法
`–storage.tsdb.retention.time` と `–storage.tsdb.retention.size` は、どちらか一方が先に限界を迎えた時点でパージが走る。
prometheus.yml の構成例
global:
scrape_interval: 15s # 闇雲に短くするな、本当に必要な解像度か？
evaluation_interval: 15s
起動引数（systemd や k8s の args）
–storage.tsdb.retention.time=15d
–storage.tsdb.retention.size=50GB
size指定は「保険」。ディスク全体の80%を超えない値に設定するのが鉄則。
開発を加速させる「神設定」とルール:
- 不要なラベルのDrop: `metric_relabel_configs` を使い、スパイクの原因となる高カーディナリティなラベル（UUIDなど）をインジェスト段階で排除せよ。
- Promlensの導入: クエリの重さを可視化する [Promlens](https://promlens.com/) は必須。複雑なクエリを書く前に必ずここでコストを叩け。
- キーボードショートカット: Prometheus UI (または Grafana Explore) で `Ctrl + Enter` を押せ。クエリの実行速度を脳に染み込ませろ。
—
4. 次のフェーズへ：Thanos/Cortexという選択
ローカルストレージに固執するのは、1台のサーバーで完結する小規模環境までだ。以下の兆候が見えたら、即座に Thanos への移行を検討せよ。
1. ディスク容量の管理に工数の5%以上を費やしている。
2. 可用性（HA）が必要になり、Prometheusを冗長化したがデータが分断された。
3. 長期保存（3ヶ月以上）のビジネス要件が発生した。
ThanosのSidecarを導入すれば、TSDBブロックをS3等のオブジェクトストレージにプッシュできる。これで「ディスク容量」という概念から解放され、クエリは必要に応じて過去の巨大なデータセットをリモートからフェッチするようになる。
—
プロからの最後のアドバイス
「監視」は、ただ数字を眺める作業ではない。「何が起きているか」を、ノイズに埋もれずに見抜くための感性を磨くプロセスだ。
Prometheusのディスクが溢れそうになった時、それは「あなたがシステムを適切にコントロールできていない」というシグナルだ。メトリクスを削れ、カーディナリティを抑えろ、そして必要であればスケールアップではなく「分散（Thanos）」を選択しろ。
明日から、Prometheusのダッシュボードを見る目が変わるはずだ。君のシステムに、平和な夜が訪れることを願っている。