Prometheusの深淵を制御せよ：TSDBストレージ最適化とスケーリングの極意
Prometheusの運用において、ストレージ不足でTSDB（Time Series Database）が破損し、監視データが消失する――。これは「運用監視の敗北」を意味する。多くのエンジニアは単にRetentionを短くして逃げるが、それではオブザーバビリティの本質を見失っている。
真のアーキテクトは、ディスク容量とクエリパフォーマンス、そしてメモリ消費の三角関係を完璧に制御下に置く。本稿では、Prometheusの内部構造を解剖し、現場で震えるほど役立つ「データ保持の最適化と長期保存への昇華」について解説する。
—
1. Prometheus TSDB：そのデータ構造の正体
PrometheusのTSDBは、「Block」という単位でデータを管理する。
- Head Block: メモリ内に保持され、現在書き込み中のデータ。
- Persisted Blocks: 2時間おきにメモリからディスクへフラッシュされる圧縮済みデータ。
この仕組み上、ストレージ容量の推移は「線形」ではなく「階段状」に増加する。重要なのは、インデックス（Index）とチャンク（Chunks）の圧縮率だ。適当なメトリクス設計は、ストレージを浪費するだけでなく、クエリ時のCPUスパイクを誘発する。
2. 鋼鉄の計算式：ストレージ予測の真実
闇雲にディスクを増やすな。以下の計算式で「必要な容量」を導き出せ。
$$ \text{Required Space} \approx \text{Retention Days} \times \text{Ingestion Rate (samples/s)} \times 3600 \times 24 \times \text{Bytes per Sample} $$
ここで重要なのは `Bytes per Sample` だ。通常、Prometheusは1サンプルあたり平均1〜2バイト程度に圧縮するが、ラベルのカーディナリティ（高すぎるLabelの組み合わせ）が爆発すると、この効率は劇的に悪化する。
- 鉄則: `count({__name__=~”.+”})` で現在の時系列数（Active Time Series）を監視し、その増加率を予測せよ。
3. ストレージ制御の神髄：設定の最適化ハック
動的変更と注意点
`–storage.tsdb.retention.time` は動的変更可能だが、適用には数分かかる。重要なのは `–storage.tsdb.retention.size` を併用することだ。時間制限のみでは、スパイク発生時にディスクが溢れるリスクがある。
推奨設定：15日間保存、ただし最大500GBまで
どちらか早い方が適用される
–storage.tsdb.retention.time=15d
–storage.tsdb.retention.size=500GB
内部ハック：WAL（Write Ahead Log）の最適化
メモリが潤沢な環境では、`–storage.tsdb.min-block-duration=2h` を調整し、書き込み頻度を制御することでIOPSの負荷を平準化できる。逆に、書き込み負荷が激しい場合は、`–storage.tsdb.wal-compression` を有効化し、ディスクIOをCPUで叩く戦略をとれ。
—
4. 自動化：プロアクティブなストレージ監視スクリプト
Prometheusが死ぬ前にアラートを飛ばすのでは遅い。容量が閾値に達する前に、自動的にクリーンアップやThanosへのオフロードをトリガーする監視の自動化だ。
!/bin/bash
Prometheusのデータディレクトリ使用量を監視し、残量不足時に警告する
THRESHOLD_GB=100
DATA_DIR=”/var/lib/prometheus”
USAGE=$(du -sh $DATA_DIR | cut -f1 | sed ‘s/G//’)
if [ “$USAGE” -gt “$THRESHOLD_GB” ]; then
# ここでThanosへのアップロードをトリガーするか、
# 冗長なメトリクスのDROP設定を動的に変更するAPIを叩く
echo “Warning: Prometheus disk space is critically low!” | mail -s “Alert” admin@example.com
fi
—
5. 長期保存への脱却：Thanos/Cortexという「神の視点」
Prometheusを単体で運用し続けることには限界がある。データが1ヶ月を超えたら、即座に Thanos Sidecar を導入せよ。
移行タイミングの見極め
- Local Disk > 500GB: 検索パフォーマンスが著しく低下し始める。
- High Availability: Prometheusがクラッシュした際、監視の空白が許されない場合。
- Long-term Query: 過去1年間のトレンド分析が必要な場合。
Thanosを導入すれば、S3/GCSといった安価なオブジェクトストレージにデータを「退避」させつつ、Prometheusのインターフェースを維持できる。これがオブザーバビリティの成熟である。
—
伝説のエンジニアからの助言
Prometheusのチューニングにおいて最も避けるべきは、「カーディナリティの爆発」だ。コード側で `user_id` や `request_id` をラベルに含めるような馬鹿げた設計は、どんなに巨大なストレージを用意しても必ず破綻する。
「ラベルは低カーディナリティに保て。高次元データはログへ逃がせ。」
これが、何十年と監視システムを設計してきた私の唯一にして最大の教訓だ。君のPrometheusが、常に静寂の中で正確に時を刻み続けることを願っている。