静的な閾値に殺されるな：PromQLによる「予測的オブザーバビリティ」の実装術
「CPU使用率が80%を超えたらアラート」。この原始的な監視から、いつまで抜け出せないつもりだ？
運用現場で我々を苦しめるのは、突発的なスパイクではない。深夜にじわじわと忍び寄り、週末のリリース直後にメモリを枯渇させる「緩やかなリーク」や、曜日・時間帯で表情を変える「周期的なトラフィック変動」だ。固定閾値など、これらに対しては無力に等しい。
今日は、Prometheusの真の力――`holt_winters`関数を用いた時系列予測と、それを実戦レベルの運用に落とし込むための「極限の設計思想」を伝授する。
—
1. なぜ固定閾値が「悪」なのか
固定閾値は、「システムの成長」と「カレンダー上の変動」を無視する。
- メモリリーク: 1週間かけて90%に達するリークは、閾値監視では最終局面まで沈黙する。
- 周期性: 月曜朝の負荷増大と深夜のスパイクを同一の閾値で判定すれば、誤検知か見逃しのどちらかが必ず発生する。
我々が求めるのは、過去のトレンドを学習し、「今の傾きが続けば、N時間後に破綻する」という未来の予測だ。
—
2. 実践：holt_wintersで未来を予見する
PromQLの `holt_winters` 関数は、過去のデータからトレンドと季節性（周期性）を抽出し、未来の値を予測する。
実践的クエリ：メモリリーク検知
「現在のメモリ使用傾向が続くと、4時間以内に閾値(90%)に達するか」を判定するクエリがこれだ。
過去4時間のデータを元に、1時間後の予測値を算出
(
holt_winters(node_memory_MemAvailable_bytes[4h], 0.3, 0.3)
/
node_memory_MemTotal_bytes
) < 0.1 # 予測結果が10%以下（＝使用率90%以上）になる場合を検知
- α (0.3): データポイントの重み。大きくすると直近の変動に敏感になる。
- β (0.3): トレンドの重み。リークのような「傾き」を捉えるには重要。
—
3. アラート設計の「神髄」：誤検知をゼロにするチューニング
予測モデルは強力だが、ノイズに弱い。以下の「防波堤」をアラートルールに組み込め。
ベストプラクティス：条件の多層化
単に予測値が閾値を超えただけではアラートを飛ばさない。「予測の確からしさ」を担保する。
groups:
- name: memory_alert
rules:
- alert: MemoryLeakingFast
# 予測値だけでなく、現在の増加率（deriv）も併用して「トレンド」を確定させる
expr: |
(holt_winters(node_memory_MemAvailable_bytes[4h], 0.3, 0.3) < 1000000000)
and
(deriv(node_memory_MemAvailable_bytes[4h]) < 0) # 減少トレンドであることを確認
for: 30m # 瞬間的なノイズを排除するため30分継続を条件にする
labels:
severity: warning
annotations:
summary: "メモリ枯渇の予兆を検知"
description: "現在の傾向が続くと、4時間以内にメモリが枯渇します。"
---
4. 現場の生産性を底上げする「プロの道具箱」
A. プロの隠れたキーボードショートカット (Prometheus UI)
- `Ctrl + Enter`: グラフの再描画。マウスでボタンを探すのは時間の無駄。
- `Shift + 矢印キー`: 時間軸の微調整。
- `Ctrl + /`: クエリ履歴の呼び出し。過去に書いた複雑なクエリを再利用する。
B. 絶対入れるべき神プラグイン・ツール
1. [PromLens](https://promlens.com/): クエリのデバッグ用。なぜその値が出たのか、どのラベルが寄与しているかを可視化する。「PromQLの深淵」を覗く唯一の手段。
2. [Grafana “Prometheus Data Source” の “Explore” 機能]: アラートを叩く前に、必ずExploreでクエリの挙動を確認すること。
C. チーム開発で役立つ「設定の共有化」ルール
- Recording Rulesの活用: 複雑な計算はAlerting Rulesに書くな。Recording Rulesで事前に集計済みメトリクスを作成し、それを参照せよ。計算コストが劇的に下がる。
- YAMLのLintとユニットテスト: `promtool` は必須だ。CI/CDパイプラインに `promtool check rules` を組み込み、構文ミスはビルド段階で弾け。
—
5. 最後に：オブザーバビリティは「哲学」である
固定閾値に頼ることは、思考を停止することと同義だ。
今回紹介した `holt_winters` は、あくまで一つのツールに過ぎない。重要なのは、「何が正常で、何が異常か」を数式で定義しようとする姿勢だ。
監視システムを構築するのではなく、システムの「健康状態を可視化するモデル」を育てる。それが、明日から君たちが現場で取り組むべき本質的なオブザーバビリティの仕事だ。
さあ、そのアラート設定ファイルを書き換えろ。無駄な夜中の呼び出しを減らし、エンジニアが本来向き合うべき「創造的な課題」に時間を割くために。