「あと何時間でサーバーが死ぬか」を計算せよ：Prometheusによる容量枯渇予測の極意
多くのエンジニアが陥る罠がある。「ディスク使用率80%でアラート」という静的閾値の設定だ。これでは、スパイクが起きた瞬間に夜中の3時に叩き起こされるか、あるいは緩やかな増加を見逃して突然サービスが停止するかの二択を迫られる。
真のオブザーバビリティとは、「現在」ではなく「時間軸の先」を監視することにある。本稿では、Prometheusの数理関数を使い倒し、障害を未然に防ぐ「予兆検知」の神髄を伝授する。
—
1. なぜ「静的閾値」はゴミなのか
80%のアラートは「結果」しか見ていない。
- 急激な増加: 10分で80%に達したなら、即座に手を打たねばならない。
- 緩やかな増加: 1年間かけて80%に達したなら、今すぐ対応する必要はない。
我々が知りたいのは「現在の使用率」ではなく「いつ枯渇するか（Time to Exhaustion）」だ。この問いに対する答えをPrometheusから引き出す。
—
2. 予測の要：`predict_linear` と `deriv` の魔法
Prometheusの強力な武器である `predict_linear` は、過去のデータから線形回帰を行い、指定時間後の値を予測する。
容量枯渇予測のPromQL
以下のクエリは、「あと24時間以内にディスクが満杯になるか？」を判定する。
ディスク残量が24時間以内に0になるノードを特定する
(
predict_linear(node_filesystem_avail_bytes[4h], 24 3600) < 0
)
- on(instance, device) group_left()
node_filesystem_size_bytes > 0
- `[4h]`: 過去4時間のデータをサンプリングする。長すぎるとノイズを拾い、短すぎると予測精度が落ちる。環境の変動幅に応じた調整が必要だ。
- `predict_linear(…, 24 3600)`: 現在の傾きを24時間先まで投影する。
- `< 0`: 予測値が負になる、つまり「24時間以内に残量がゼロになる」ことを意味する。
変化率を可視化する `deriv`
急激な書き込み増加を検知したいなら `deriv` が最強だ。これは単位時間あたりの変化量（傾き）を返す。
1時間あたりのディスク消費速度（バイト単位）
deriv(node_filesystem_avail_bytes[1h])
これを使えば、「急激なログの暴走（書き込み加速）」を閾値監視できる。
—
3. 実践：誤検知を防ぐチューニングとダッシュボード構成
予測アラート最大の敵は「ノイズ」だ。以下のステップで精度を極限まで高める。
ステップ1：`for` 句によるフィルタリング
予測値が瞬間的に0を下回ってもアラートを出さない。`for: 30m` を設定し、30分間予測が継続した場合のみ発報する。
groups:
- name: capacity_prediction
rules:
- alert: DiskWillBeFullIn24Hours
expr: predict_linear(node_filesystem_avail_bytes[4h], 24 3600) < 0 for: 30m # 瞬間的なノイズを無視する labels: severity: critical annotations: summary: "ディスク枯渇予兆: {{ $labels.instance }}" description: "現在の消費傾向に基づくと、24時間以内に容量が枯渇します。"
ステップ2：神ダッシュボードの構築
Grafanaに「枯渇までの残り時間」を表示するゲージパネルを作れ。
- クエリ: `(node_filesystem_avail_bytes / -deriv(node_filesystem_avail_bytes[4h])) / 3600`
- 単位: `h` (時間)
- 効果: 監視担当者が「あと何時間で動けなくなるか」を一目で判断できる。これが安心感を生む。
—
4. プロの隠しコマンドと共有ルール
開発スピードを上げるショートカット
- Prometheus UI: `Ctrl + Enter` でクエリ実行。`Shift + Enter` で改行。
- Grafana: `p + d` でダッシュボードの複製。`d + r` でリフレッシュ。
チーム開発のベストプラクティス
1. Recording Rulesの活用: 複雑なクエリは必ず `recording rules` としてサーバーサイドで事前計算させる。これだけでダッシュボードの読み込み速度が10倍変わる。
2. 設定ファイルの共通化: アラート定義を `rules.yaml` で管理し、ディレクトリ構造を `namespace/component/rules.yaml` に統一せよ。
3. JSON形式で共有: GrafanaのダッシュボードはJSONでエクスポートし、Gitで管理すること。変更履歴なしでダッシュボードをいじるのは、泥酔状態で高速道路を運転するのと同じだ。
—
最後に：アーキテクトからの助言
監視設定とは「コード」だ。一度書いて終わりではない。システムが成長すれば書き込みパターンも変わり、予測精度は劣化する。
定期的に `predict_linear` の期間（`[4h]` の部分）を見直し、現実の負荷と乖離していないかを確認せよ。「監視が壊れていないか」を監視する監視こそが、本当のプロフェッショナルがたどり着く領域だ。
さあ、今すぐ静的閾値を消し去り、予測可能なインフラを手に入れよう。君のチームの眠りは、その小さなPromQLの改善から始まる。