【入門編】Prometheus WAL(Write-Ahead Log)の徹底解剖：クラッシュリカバリの仕組みと破損時の手動修復リカバリ手順 – 運用監視・オブザーバビリティ活用バイブル

Prometheusの「心臓」を守る：WAL（Write-Ahead Log）の深淵と、壊れた瞬間の救出術

やあ。Prometheusを運用していて、朝一番に「CrashLoopBackOff」の通知が飛んできて心臓が止まりそうになった経験はないかな？

Prometheusはメトリクス監視の王様だが、その信頼性の根幹を支えているのはWAL（Write-Ahead Log）という仕組みだ。今日は、ドキュメントの表面をなぞるような話はしない。「Prometheusがなぜ死ぬのか」「死んだ時にどうやって魂（データ）を救い出すのか」という、現場で生き残るための知見を授けよう。

—

1. WALとは何か？：Prometheusの「短期記憶」

Prometheusは、受け取ったメトリクスを即座にディスク上のTSDB（時系列データベース）に書き込むわけではない。効率のためにメモリ上で塊（チャンク）を作り、ある程度の時間が経ってからディスクへフラッシュする。

しかし、もしその間に電源が落ちたら？メモリ内のデータは消滅し、監視の穴が空いてしまう。そこで登場するのがWALだ。

役割: メモリに書き込む前に、変更内容を逐次ディスクへ追記する。「万が一」の時に、このログをリプレイすればメモリの状態を完全再現できるというわけだ。
構造: `/data/wal/` ディレクトリ配下に `000001`, `000002` といった連番のセグメントファイルとして保存される。

2. なぜWALは「破損」するのか？

WALが壊れる原因はシンプルだ。
1. ディスク容量の枯渇: 書き込み途中で領域が尽き、不完全な末尾が残る。
2. 突然の電源断・ハードウェア障害: 書き込みが中途半端に終了し、ファイル構造に不整合が生じる。
3. ファイルシステムのエラー: 物理的な劣化やカーネルパニック。

Prometheusは起動時にこのWALを読み込み、メモリを構築する。ここで「CRC（巡回冗長検査）エラー」や「不正なレコード」が見つかると、Prometheusは安全のために起動を拒否する。それが「起動ループ」の正体だ。

—

3. 現場で使える「救出」の作法：プロのリカバリ手順

ここからは、実際にWALが破損した際の「外科手術」の手順だ。焦ってはいけない。まずはバックアップだ。

ステップ1：現状の完全バックアップ

まずは壊れたデータディレクトリを丸ごとコピーしよう。

復旧作業は必ずコピーに対して行うこと。失敗したら最初からやり直せるように。
cp -r /data/prometheus /data/prometheus_backup_$(date +%Y%m%d)

ステップ2：walchkツールで犯人を特定する

Prometheusには `promtool` という強力なツールが同梱されている。これを使って、どのセグメントが壊れているのかを特定する。

破損箇所の特定
/usr/local/bin/promtool tsdb walchk /data/prometheus/wal

もし破損していれば、以下のようなメッセージが出るはずだ。
> `Error: … WAL segment 000005 is corrupted`

ステップ3：破損したセグメントを「切り捨てる」

「破損したデータは諦める」というのが、Prometheusのデータ整合性を保つための唯一の正解だ。該当するセグメントファイルを退避、あるいは削除する。

破損したセグメントをディレクトリ外へ移動（削除ではないのがポイント）
mv /data/prometheus/wal/000005 /tmp/corrupted_wal_000005

ステップ4：最後の仕上げ（truncate）

稀に、最後のセグメントだけが不完全な場合がある。その場合は `truncate` コマンドで不整合箇所を切り詰めることもできる。

最後のセグメントを整合性が取れる位置まで切り詰める
/usr/local/bin/promtool tsdb truncate /data/prometheus/wal 000005

—

4. 初心者が絶対やるべき「HelloWorld」的セットアップ

そもそも壊さない運用が一番の近道だ。以下の設定を確認してみてほしい。

prometheus.ymlの重要ポイント:

global:
scrape_interval: 15s # 頻繁すぎるとWALへの負荷が増える
evaluation_interval: 15s

storage:
tsdb:
# 保持期間を適切に設定する（長すぎるとWALの負荷とリカバリ時間が跳ね上がる）
retention.time: 15d

動作確認の極意:
`http://localhost:9090/status` にアクセスし、「Build Information」と「TSDB Status」を確認する癖をつけよう。特に「WAL Replay Time」が極端に伸びていたら、それはWALが肥大化しているサインだ。

—

最後に：オブザーバビリティの神髄

「ツールが壊れたら、ログを見て直す」。これは技術者として最低限のスキルだ。しかし、真のオブザーバビリティ・エンジニアは、「なぜ壊れたか」を考える。

ディスクのI/O Waitは高くないか？
ログのローテーション設定は適切か？
そもそも、この監視基盤自体を冗長化（PrometheusのHA構成やThanos/Cortexの導入）すべきではないか？

WALの破損は、システムがあなたに「ここを改善してくれ」と送っている悲鳴だ。これを乗り越えれば、あなたはもう単なる運用担当者ではない。システムの守護者だ。

また何か詰まったら、いつでも聞きに来るといい。現場での健闘を祈るよ。