Prometheusの「深淵」を覗く：predict_linearとrate/irateの数理と実践
多くのエンジニアがPrometheusを「単なるメトリクス収集ツール」だと思っている。だが、それはフェラーリで近所のコンビニに買い物に行くようなものだ。
PromQLの真の力は、単なるデータの可視化ではない。「未来を演算し、現在のノイズを排除する」ことにある。今日は、インフラの限界を数学的に予測し、誤報に振り回されないアラートを設計するための、現場の最前線でしか語られない「武器」を授ける。
—
1. 未来を演算する：predict_linearの数理的本質
ディスク枯渇やメモリリークの検知において、「閾値を超えたら発報」というのは原始的な手法だ。我々が知りたいのは「あと何時間で死ぬか」である。ここで `predict_linear` の出番だ。
数理モデルの解釈
`predict_linear(v range-vector, t scalar)` は、指定された範囲のデータに対して単純線形回帰を行い、`t` 秒後の値を予測する。
$$y = ax + b$$
この数式における傾き（$a$）を過去データから算出し、現在から $t$ 秒後の未来を線形外挿する。
実践：ディスク枯渇予測アラート
「ディスクが残り10%を切る」ではなく、「残り24時間で容量が尽きる」を検知する。
予測値が10(GB)を下回る場合を検知（24時間後の予測）
predict_linear(node_filesystem_avail_bytes[4h], 24 3600) < 10 1024 1024 1024
【テックリードの知見】
`predict_linear` は過去のトレンドに大きく依存する。突発的なバースト負荷で予測が暴れるのを防ぐため、`[4h]` 程度の長めのレンジベクトルを渡し、平滑化して使うのが鉄則だ。
—
2. rate vs irate：エンジニアが陥る「平均の罠」
カウンター値（増加し続けるメトリクス）を扱う際、あなたは `rate` か `irate` かを選択しなければならない。
- `rate` (平均レート): 指定された時間範囲の平均を出す。滑らかだが、スパイク（瞬間の負荷）を見落とす。
- `irate` (瞬間レート): 最後の2つのデータポイントのみで計算する。スパイクの検知には最強だが、グラフがギザギザになりすぎて視覚的な傾向を掴みにくい。
使い分けの黄金律
- ダッシュボード（視覚化）: 基本は `rate`。トレンドを把握するため。
- クリティカルなアラート: `irate` を採用すべき。例えば、HTTP 5xxエラーの急増など、「平均化されて隠れてしまう短時間の障害」を許容してはならない。
—
3. 現場で「震えるほど役立つ」実践テクニック
神プラグインと設定のベストプラクティス
Prometheusの設定をYAMLで管理する場合、`prometheus.yml` は分割せよ。
prometheus.yml の構成案
rule_files:
- “rules/alerts/.yml” # アラート定義を機能ごとに分離
- “rules/recording/.yml” # 重い計算はRecording Ruleで事前生成
【必須ツール】
- [PromLens](https://promlens.com/): PromQLを視覚的にデバッグできる最強のツール。複雑なクエリを書くなら、まずここで構造を理解せよ。
- [Prometheus Operator](https://prometheus-operator.dev/): Kubernetes環境なら必須。`ServiceMonitor` を使うことで、エンジニアが監視設定を直接リポジトリへPull Requestとして送れるフローを構築できる。
チーム開発のための「クエリ共有化ルール」
生クエリをそのままコードに書くのはNGだ。`Recording Rules` を活用し、複雑なロジックは名前付きのメトリクスとして抽象化せよ。
良い例（Recording Ruleでの抽象化）:
groups:
- name: application_health
rules:
- record: job:http_error_rate_5m
expr: sum by (job) (rate(http_requests_total{status=~”5..”}[5m]))
こうすることで、ダッシュボードやアラート設定で `job:http_error_rate_5m` を叩くだけで済む。修正が必要な際も一箇所の変更で済む。
—
最後に：オブザーバビリティは「哲学」である
Prometheusは、あなたが「何を重要だと考えているか」を正直に反映する。`predict_linear` で未来を予測し、`irate` で瞬間の異常を切り取り、`Recording Rules` で複雑さを隠蔽する。
これらは単なる技術ではない。「システムがいつ死ぬかを理解し、死ぬ前に手を打つ」というエンジニアの責務を果たすための哲学だ。
さあ、今すぐ `irate` を使って、あなたの見逃していたその「小さなスパイク」を可視化することから始めてみてほしい。現場の静寂は、あなたがどれだけ深くメトリクスを読み解いたかによってのみ作られるのだから。