# Prometheusルールリント ## 定義 Prometheusルールリント(Prometheus Rule Linting)とは、Prometheus の alerting rule / recording rule が**実際のライブ Prometheus と整合しているか**を静的解析 + ライブクエリで検証し、「監視が静かに壊れている」状態を早期発見するプラクティスである。「監視の監視(monitoring the monitoring)」または watchdog monitoring パターンとも呼ばれる。 ## 問題背景: 空クエリの沈黙 Prometheus はクエリが何も返さないとき**エラーを出さない**。これが根本的な問題を引き起こす: > 「アラートが来ない」= 「すべて正常」**か**「監視が壊れている」 この 2 つを Prometheus は区別しない。発見できるのは以下のような典型的故障パターン: | 故障パターン | 原因 | 検知難易度 | |---|---|---| | タイポ | `http_requests_totals`(末尾に s) | 低 | | メトリクス廃止 | node_exporter アップグレードで名称変更 | 中 | | ラベル変更 | `status` → `code` | 中 | | rate() 時間範囲不足 | scrape interval 1m で `rate(metric[1m])` | 高 | | recording rule 連鎖切断 | 中間 recording rule を別チームが変名 | 高 | ## rate() の 2 点問題 `rate()` は少なくとも 2 データポイントが必要。scrape interval が 1 分の場合: - `rate(metric[1m])` → 最大 1 点のみ取得 → rate 計算不能 → 空の結果 → **アラート永遠に発火しない** - 正しい時間範囲は scrape interval の 4 倍以上が目安 ## recording rule 連鎖と脆弱性 ``` metric_raw └─ recording_rule_1 (チーム A) └─ recording_rule_2 (チーム B) └─ alerting_rule (チーム C) ``` チーム B が `recording_rule_2` を変名すると、チーム C のアラートは静かに停止する。唯一の兆候は「アラートが来なくなる」だけ。 ## 対策: ルールリント Prometheusルールリントの実装戦略は 3 段階: 1. **静的解析**: PromQL 構文検証(閉じ括弧、演算子ミスマッチ等) 2. **ライブ検証**: 実際の Prometheus に対してメトリクス・ラベルの存在確認。rate() の時間範囲妥当性チェック 3. **デーモン監視**: 定期的にルールをライブ検証し、問題をメトリクスとして公開 → Prometheus でアラート化 [[pint]] は Cloudflare が実装したこの 3 段階すべてを網羅するツール。 ## 横断的知見 ### 発火前 vs 発火後の介入 [[アクショナブルアラート]] の議論はほぼ「発火したアラートの品質改善」に集中する: - [[Quality of Alerts]]: 真/偽/欠落の 3 分類(Zadka 2022) - KEEP/TUNE/DELETE による定期的な衛生管理([[認知的徒弟制]]、Paige Cruz 2023) Prometheusルールリントは**発火前**の介入——「ルールが正しく発火できる状態にあるか」を保証する。両者は直交する介入点である。 ### Prometheus unit testing との違い Prometheus 標準の unit testing(mock データによる論理検証)は、クエリロジックの正しさは確認できるが「そのメトリクスが実際に存在するか」は確認できない。ルールリントは unit testing を補完し、ライブ環境とのズレを検出する。 ### CI と常時ウォッチドッグの組み合わせ - **CI モード**: PR 時に変更ルールのみ検証 → 劣化の「挿入」を防ぐ - **デーモンモード**: デプロイ後の変化(メトリクス廃止・ラベル変更)による「漸進的劣化」を検出 ### 時系列アラートの初期利点と後年のリント問題 [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]] は、静的閾値ではなく時系列データを使うことで、現在のディスク使用率ではなく将来の枯渇見込みに対してページできる利点を示した。これは Prometheus ルールの強みだが、後年の [[@2022__Cloudflare-Blog__Monitoring-our-Monitoring]] が示したように、時系列クエリでアラートを定義するほど、メトリクス名・ラベル・`rate()` 範囲・recording rule 連鎖の静かな破損が新しい故障モードになる。したがって Prometheusルールリントは、時系列ベースアラーティングが普及した後に必要になった二次的な品質保証層である。 ## 実装 - [[pint]]: Cloudflare OSS。GitHub: https://github.com/cloudflare/pint - `promql/series` チェック: 過去 1 週間で存在しないメトリクスを報告。recording rule が生成するメトリクスは適切にスキップ ## 関連 - ソース: [[@2022__Cloudflare-Blog__Monitoring-our-Monitoring]] / [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]] - ツール: [[pint]] / [[Prometheus]] - 概念: [[アクショナブルアラート]] / [[アラート管理]] / [[オブザーバビリティ]]