Prometheus WALの深淵：クラッシュリカバリの神髄と、死の淵からデータを生還させる外科手術
Prometheusを運用する者にとって、WAL（Write-Ahead Log）は単なるログファイルではない。それは「時系列データの命そのもの」であり、メモリ上の未コミットデータと、ディスク上の不変データ（TSDBブロック）を繋ぐ唯一の生命線だ。
Prometheusが突如として再起動し、起動ログに `WAL corruption` の文字が踊る時、多くのエンジニアは「データ削除」という安易な選択に逃げる。だが、伝説的なアーキテクトは決してそれを許さない。今日は、WALの内部構造を解剖し、破損を外科手術のように修復する極限の技術を伝授する。
—
1. WALの解剖学：メモリとディスクの狭間で
Prometheusは、高頻度なTSDBブロック生成の負荷を避けるため、受信したサンプルをまずメモリ内の `Head` に蓄え、同時にWALにシーケンシャル書き込みを行う。
- セグメントの構造: WALは複数のセグメントファイル（`000001` 等）で構成される。
- チェックポイント: 定期的にHead内のデータをTSDBブロックとして圧縮・永続化し、古いWALセグメントを破棄する。
- クラッシュリカバリ: Prometheus起動時、このWALを先頭からリプレイし、Headの状態を完全に再現する。
ここで重要なのは、「WALが破損するということは、このリプレイプロセスが途中で強制終了する」ことを意味する。原因はディスクI/Oのハングアップ、強制的なOOM Killerによるプロセス停止、あるいはファイルシステムの不整合だ。
—
2. 破損の検知と `promtool` の限界を超えて
WALが破損すると、Prometheusはリプレイに失敗し、以下のエラーを吐いて停止する。
level=error msg=”Opening storage failed” err=”wal: segment 000012: invalid record length”
公式の `promtool tsdb analyze` は便利だが、破損個所の特定には力不足な場面が多い。我々が使うのは、よりプリミティブかつ強力なツール群だ。
手動修復のステップ：外科手術の手順
Step 1: データの完全バックアップ（絶対遵守）
何をおいても、`data/` ディレクトリ全体を別ボリュームに `rsync` せよ。修復作業は「破壊的」である。失敗した時に元に戻せる保証がないなら、最初から手を出すな。
Step 2: 破損セグメントの特定
`promtool` を駆使し、どのセグメントが死んでいるかを特定する。
破損したWALセグメントの特定
./promtool tsdb walchk /path/to/data/wal
Step 3: 破損データの切り捨て（Truncation）
`walchk` が破損箇所を指摘した場合、そのセグメントの「正常な部分」までを維持し、以降を削除する。これにはGoで書かれた小さなツールか、`dd` を用いたバイナリカットが必要だ。
エキスパートハック: 破損したセグメントの末尾を `dd` で切り落とす際のコマンド例：
破損したセグメントを特定し、正常なオフセットまでを切り出す
※危険：オフセット計算をミスれば全データが消失する
dd if=000012 of=000012.fixed bs=1 count=[破損開始オフセット]
—
3. なぜWALが破損するのか？（低レイヤの教訓）
WAL破損の多くは、実はアプリケーションのバグではなく、インフラストラクチャの怠慢だ。
1. ディスクI/Oのレイテンシ: PrometheusはWALの書き込み時に `fsync` を呼ぶ。これが遅延すると、バッファがフラッシュされないままOSがクラッシュする。
- 対策: `iostat -x` で `%util` を監視し、100%に張り付くようなら即座にSSDのオーバープロビジョニング設定を見直せ。
2. OSのメモリオーバコミット: `vm.overcommit_memory = 1` はPrometheusを殺す。OOM Killerに殺されると、WALはほぼ確実に不整合を起こす。
- 対策: `cgroup` でメモリ上限を厳格に制御し、`oom_score_adj` を調整してシステムを道連れにしない設定にせよ。
—
4. 完全自動リカバリ：SREのためのパイプライン構築
手動修復は緊急用だ。真のアーキテクトは、破損を検知した瞬間に修復が走る自動化パイプラインを持つ。
!/bin/bash
破損検知自動リカバリ・スケルトン
WAL_DIR=”/data/prometheus/wal”
if ! ./promtool tsdb walchk “$WAL_DIR” > /dev/null 2>&1; then
echo “WAL Corruption detected! Initiating surgical recovery…”
# 1. 自動バックアップ
tar -czf /backup/prometheus_$(date +%s).tar.gz /data/prometheus/
# 2. 破損セグメントを特定し、安全なポイントまで削除するカスタムスクリプトを実行
./scripts/repair_wal.sh “$WAL_DIR”
# 3. 再起動
systemctl restart prometheus
fi
—
5. アーキテクトの結論：データ損失をゼロにする設計思想
WAL破損に怯えるのは、Prometheusを「単体」で運用しているからだ。真のオブザーバビリティを追求するなら、以下の設計思想へ移行せよ。
- Remote Writeの活用: WALに依存せず、受信したデータを即座に長期保存用DB（ThanosやCortex, Mimir）へ流せ。Prometheusのローカルストレージは「キャッシュ」として扱う。
- TSDBの分離: `data/` を高速かつ堅牢なNVMeストレージに配置し、WALの書き込みレイテンシを極限まで下げる。
- シャットダウンの最適化: 終了シグナルを捕まえた後、`SIGTERM` を投げっぱなしにするのではなく、データのフラッシュを待つための `TimeoutStopSec` を適切に設定せよ。
PrometheusのWALを掌握するということは、時系列データという「ITの心臓」を直接触ることに等しい。恐れることはない。仕組みを理解し、低レイヤの挙動を制御できる者だけが、真の監視システムを設計できるのだ。
さあ、次は君の番だ。壊れたWALの断片から、かつてのシステムの鼓動を復元してみせろ。