Prometheusの深淵：PromQLで「未来」を計算し、ノイズを殺す極限のアーキテクチャ
「監視」という言葉に甘んじるエンジニアは、障害の事後処理で一生を終える。オブザーバビリティとは、システムの現在地を観測することではない。「システムがいつ破綻するか」という未来の座標を、数学的に導き出すことだ。
Prometheusの真髄は、単なる時系列データの保存場所にあるのではない。その心臓部であるPromQLを、カーネルレベルの挙動と統計モデルで制御する。今回は、現場で「神」と呼ばれるレベルのオブザーバビリティを実現するための、PromQL活用術を伝授する。
—
1. predict_linear: 枯渇の予兆を捉える数理モデル
多くのエンジニアが `predict_linear` を「ディスク容量監視の便利ツール」程度に捉えている。だが、これは「直近N時間の線形回帰」をリアルタイムで実行する強力な統計エンジンである。
数理的本質
`predict_linear(v range-vector, t scalar)` は、指定した期間のデータに対して最小二乗法（Ordinary Least Squares）を適用し、t秒後の値を予測する。
- 落とし穴: データ点数が少なすぎる（あるいはスパイクが激しい）場合、回帰直線は容易に暴れる。これを防ぐには、単に `1h` ではなく、トラフィックの周期性を考慮した期間設定が必要だ。
実践的ユースケース：ディスク枯渇の完全予兆検知
単に「残り10%」でアラートを鳴らすのは素人の所業だ。我々は「あと何時間で死ぬか」を予測する。
ディスク残量が4時間以内にゼロになるか、あるいはあと10GBしかない場合に発報
(
predict_linear(node_filesystem_avail_bytes{mountpoint=”/”}[4h], 4 3600) < 0
)
or
(
node_filesystem_avail_bytes{mountpoint="/"} < 10 1024 1024 1024
)
アーキテクトの視点:
このクエリをアラートマネージャーで叩く際、`for` 句を短くしすぎてはいけない。線形回帰の傾きが安定するまで、少なくとも予測に使用する期間の2倍以上の評価時間を設けるのが鉄則だ。
—
2. rate vs irate: 粒度の解像度を支配する
`rate` と `irate` の違いを「スライディングウィンドウの計算」とだけ理解しているなら、貴方の監視は甘い。
- `rate()`: 範囲内（range）の平均をとる。スパイクを平滑化する。長期的な傾向分析に最適。
- `irate()`: 直近2つのデータ点のみを参照する。瞬発的なバーストを逃さない。
究極の使い分け
- 長期トレンド・SLO監視: `rate` 一択だ。CPU使用率の平滑化や、HTTPリクエストの1分間平均などはこれで十分。
- 瞬間的な負荷によるカーネルパニック検知: `irate` が必須となる。例えば、ネットワークインターフェースの瞬時輻輳を検知する場合、`rate[5m]` では平均化されて消えてしまう。
プロのハック:
高頻度でスクレイピングしている場合、`irate` はノイズを拾いすぎる。逆に低頻度の場合、`rate` は偽の平穏を見せる。「スクレイピング間隔の3倍」を `rate` の範囲に設定するのが、エイリアシングを回避する黄金律である。
—
3. 障害予兆検知：エラートラッキングの設計思想
障害の予兆は、エラー数そのものではなく「エラーの加速度」に現れる。
実践：成功率の下落を「傾き」で検知する
単にエラー率が閾値を超えた時ではなく、その上昇率が異常な時にアラートを飛ばす。
直近5分のエラー率の移動平均が、過去1時間の平均と比較して急上昇しているか
(
rate(http_requests_total{status=~”5..”}[5m])
/
rate(http_requests_total[5m])
)
/
(
rate(http_requests_total{status=~”5..”}[1h])
/
rate(http_requests_total[1h])
) > 3
このクエリの狙い:
エラー率が定常的に高いサービス（レガシーなシステムなど）でも、相対的な急上昇のみを抽出できるため、ノイズを劇的に削減できる。これが「監視疲れ」を防ぐ唯一の方法だ。
—
4. パフォーマンス最適化の極致：メモリ消費との戦い
Prometheusのメモリ消費は、「アクティブな時系列数（Series）」と「クエリの評価範囲（Lookback Delta）」で決まる。
1. 高カーディナリティの排除: ラベルに `user_id` や `request_id` を含めるのは自殺行為だ。Prometheusはメモリが許す限り全データを保持しようとする。ラベルの正規化を徹底し、カーディナリティを抑えよ。
2. Recording Rulesの活用: 頻繁に実行する複雑なPromQLは、すべてRecording Rule（事前計算）に焼き込め。ダッシュボードを開くたびに `predict_linear` を計算させるな。API経由で `prometheus.yml` に動的にルールを注入し、CI/CDで管理するのが現代のDevOpsの姿だ。
3. Recording Ruleの階層化:
- Tier 1: 生データから `rate` を計算（1分間隔）
- Tier 2: `rate` を使った統計処理（5分間隔）
- Tier 3: アラート用閾値判定
—
最後に：アーキテクトからの助言
監視ツールは、単なる「表示器」ではない。システムと対話するためのインターフェースだ。PromQLの関数は、数学という共通言語でシステムの状態を記述している。
「なぜこのクエリなのか？」「この期間でなければならない根拠は何か？」を言語化できないうちは、監視とは呼べない。メトリクスに血を通わせ、システムの鼓動を予測せよ。そうすれば、障害が起きる前に、貴方はコーヒーを片手に解消ボタンを押すことができるはずだ。
技術は裏切らない。ただ、設計者の解像度に比例して、その牙を剥くか、盾となるかが決まるだけだ。