閾値アラートは「死の宣告」である：PromQLで切り拓く容量枯渇の予兆検知
多くの現場が「ディスク使用率90%でアラート発報」という原始的な閾値監視に依存している。しかし、それは「崖っぷちで警報を鳴らす」ことに過ぎない。インフラエンジニアが深夜3時に叩き起こされるのは、その90%が数ヶ月かけて到達したものなのか、あるいはわずか15分で急上昇したものなのかを判断できず、すべてを「即座の対応が必要な緊急事態」として扱うからだ。
真のオブザーバビリティとは、現在の状態を監視することではなく、「システムの未来を計算すること」にある。今回は、Prometheusの奥義である `predict_linear` と `deriv` を使い、容量枯渇を「事故」から「計画的なメンテナンス」へと昇華させる手法を伝授する。
—
1. 閾値監視という「負債」の正体
`node_filesystem_avail_bytes` を見て 80% や 90% でアラートを投げる手法は、以下の理由で破綻する。
- ホワイトノイズの嵐: 急激なスパイクによる一時的な使用率上昇で無駄なアラートが飛び、PagerDutyが鳴り止まなくなる。
- 「時間」という軸の欠落: あと何時間で破綻するのか？という最も重要な情報が隠蔽されている。
- 非効率なリソース割り当て: 余裕があるのに「閾値を超えた」という理由だけで深夜の緊急対応を強いられるコスト。
我々が求めるべきは、「現在の傾向が続いた場合、何時間後に破綻するか（Time-to-Saturation）」という逆算の思考だ。
—
2. 予測の神髄：predict_linear と deriv の活用
PromQLにおいて、線形回帰は強力な武器となる。
2.1. 枯渇まで残り何時間かを計算する
`predict_linear` は、過去の一定期間のデータから未来の値を推測する。これを利用し、「未来の時点での値が0になる時間を算出する」のが定石だ。
ディスク枯渇まで残り何時間あるかを計算するクエリ
(
# 現在の空き容量
node_filesystem_avail_bytes{mountpoint=”/”}
/
# 過去4時間における1時間あたりの減少速度（derivで算出）
abs(deriv(node_filesystem_avail_bytes{mountpoint=”/”}[4h]))
) / 3600
2.2. 実戦的なアラートルール
単に「残り時間」を見るだけでは誤検知を生む。`predict_linear` を使い、「4時間後に容量がゼロになる」という条件でアラートを組むのが最も実用性が高い。
groups:
- name: capacity_forecast
rules:
- alert: DiskWillFillIn4Hours
# 過去4時間の傾向から、4時間後の空き容量が0になる（マイナスになる）場合
expr: predict_linear(node_filesystem_avail_bytes{mountpoint=”/”}[4h], 4 3600) <= 0
for: 15m # 瞬間的なノイズを排除するため
labels:
severity: critical
annotations:
summary: "容量枯渇の予兆: {{ $labels.instance }}"
description: "現在の傾向が続くと、4時間以内にディスクが枯渇します。"
---
3. 誤検知を防ぐための「高度なチューニング」
`predict_linear` は強力だが、データが荒れていると予測値も乱れる。以下のハックを適用せよ。
① `holt_winters` による平滑化
`predict_linear` は単純な線形回帰だが、もしトラフィックに周期性があるなら `holt_winters` を検討すべきだ。ただし、容量予測においては「単調減少」を前提とするため、線形回帰の方が安定するケースが多い。
② 指数移動平均 (EMA) の適用
生データを `rate` や `deriv` に入れる前に、`avg_over_time` や `predict_linear` の入力ウィンドウを長くとることで、突発的なスパイクを平滑化する。
③ アラートの「二段構え」
- 予報 (Warning): `24時間以内` に枯渇（チケット起票・Slack通知）
- 警告 (Critical): `4時間以内` に枯渇（オンコール呼び出し）
—
4. ダッシュボード構築のアーキテクチャ
単にグラフを描画するだけでなく、「Time-to-Zero」を可視化せよ。Grafanaの「Stat」パネルに、上記クエリで算出した「枯渇までの時間」を表示させる。これがチームの心理的安全性を劇的に高める。
- Legendのカスタマイズ: `{{instance}} – {{mountpoint}}` とし、どのサーバがボトルネックか即座に判別できるようにする。
- Thresholdの設定: 24h以下を黄色、4h以下を赤色にする。
—
5. エキスパートとしての「低レイヤ」の視点
最後に、Prometheusのメモリ消費とパフォーマンスについて忠告しておく。
- クエリの計算量: `predict_linear` は広範囲なレンジベクトルを計算するため、頻繁に叩くとPrometheusのクエリエンジンに負荷がかかる。アラートルールは `1m` よりも `5m` や `10m` の間隔で実行するようにせよ。
- データの解像度: `deriv` はデータポイントが極端に少ないと精度が落ちる。`scrape_interval` が長い場合は、`[4h]` などの長いレンジベクトルを指定し、十分なサンプル数を確保することが不可欠だ。
魂の教訓
ツールは「監視」するためにあるのではない。「意思決定」を自動化し、人間がより創造的な設計に集中するためにある。閾値アラートを捨て、予測に基づくプロアクティブな運用へ移行せよ。それが、システムを掌握したエンジニアにのみ許される、唯一の道だ。