# Prometheus クラウドネイティブな時系列モニタリングシステムのオープンソース de facto 標準。データコレクタがメトリクスを scrape してストレージへ送り、PromQL でクエリする。recording rule / alerting rule による**周期的ルールクエリ**を支援する。時系列特化のストレージエンジンを持つ [[時系列データベース|TSDBMS]] に分類される。 [[@2025__VLDB__Approximation-First Timeseries Monitoring Query At Scale]] では、ルールクエリの繰り返しデータスキャン(CPU 時間の 41%)と重複ウィンドウの繰り返し計算が主要ボトルネックと特定された。各周期ルールクエリを独立に再計算し、重複区間の中間結果を再利用しない点が問題とされる。[[PromSketch]] は約 30 行のパッチで統合され、クエリ処理コストを約 400× 削減する。 [[@2024__IEEE CLOUD__Enabling Programmable Metric Flows]] では、Prometheus Remote Write プロトコルでメトリクスを PMF プロセッサ経由で中央アグリゲータ（Cortex）へ送信する構成のベースラインとして使用される。Prometheus の固定 30 秒収集間隔に対し、PMF のトップダウン動的周波数最適化は同一帯域で重み付き再構成誤差を約 600 倍削減する。 ## ルール品質保証 Prometheus は alerting rule / recording rule が空の結果を返す場合にエラーを出さない。これが「監視の静かな失敗」を引き起こす。[[Cloudflare]] は [[pint]] でこの問題に対処し、CI および常時デーモンによる[[Prometheusルールリント]]を実現した。([[@2022__Cloudflare-Blog__Monitoring-our-Monitoring]]) Cloudflare の大規模事例: 単一 Prometheus で時系列数ピーク約 3,000 万。1 時系列 ≈ 4 KiB のメモリが目安。 ## アラーティング用語と時系列予測（SoundCloud 事例） [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]] では、SRE Book が monitoring output と呼ぶ分類に対し、Prometheus の用語では即時対応を促すものを Alerts と呼ぶと説明される。SoundCloud の運用ではこれを Pages（pager へ配送）、Tickets（issue tracker / email）、Informational alerts（nowhere / dashboards）に分け、Prometheus 的な alerts を「人を起こすページ」として扱う。 同発表は、静的なディスク満杯アラート（Nagios 例）と時系列ベースのディスク満杯アラート（Prometheus 例）を対比し、現在の使用率が高いだけでは鳴らさず、傾きから近い将来に満杯へ向かう場合だけ鳴らす設計を示した。これは Prometheus を「時系列データからアラートを生成する」実践の早い事例として位置づける。 ## ラベル付き時系列と記録ルール（Wilkinson 2017） [[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale]] は、Prometheus を大規模監視設定の保守コストを下げる抽象として説明する。サービス発見でターゲットを列挙し、`/metrics` をスクレイプし、ラベル付き時系列を TSDB に記録し、ルールセットを評価して Alertmanager へ送る流れで構成される。 同資料の後半では、`task:requests:rate10s` のような記録ルール名を「レベル・操作・名前」の構造として扱い、`dc:requests:rate10s`、`global:requests:rate10s` へトポロジに沿って集約する。さらに、`dc:errors:ratio_rate10s` の例で、エラー率をリクエスト率とスキーマ上の `job` ラベルで結合して計算する。これは Prometheus のラベルモデルを、単なるメトリクス命名ではなく、組織的な監視抽象として使う初期の実践例である。 ## 分散配置とフェデレーション（Cloudflare 事例） [[@2017__SREcon17 Europe__Monitoring Cloudflare's Planet-Scale Edge Network]] では、116 の PoP それぞれに独立した Prometheus を配置し、コアデータセンターの Prometheus へフェデレーションで集約するアーキテクチャが報告された。Prometheus にクラスタリングがなく、サーバー間で共有状態を持たない設計は、監視を監視対象と同じ障害ドメインに配置するための意図的な選択とされる。各 PoP 内では高可用性のため複数の独立した Prometheus インスタンスが同一サーバー群を並行スクレイプし、Alertmanager がゴシッププロトコルで通知を重複排除する。ゴシップ失敗時は重複通知を許容する（通知漏れより重複を選択）。 ## 高頻度デプロイとシリーズチャーン（Vernekar 2026） [[@2026__SREcon26Americas__Unlock High-Frequency Deployments without Blowing Up Prometheus]] では、Kubernetes 高頻度デプロイが引き起こす**シリーズチャーン**問題と、Prometheus v3.10.0 で実験的に導入された **stale-series compaction** が解説された。 - pod ラベルを持つメトリクスは、Deployment ロールアウトのたびに pod suffix が変わり、旧系列が失活系列(stale series)として HEAD(RAM)に 2 時間残り続ける - StatefulSet でも instance ラベル(IP)が変わるたびに同様の現象が起きる - `stale_series_compaction_threshold: <0.0-1.0>` を設定すると失活系列比率がその値に達した時点でディスクへ先回りフラッシュし OOM を回避できる - トレードオフ: クエリ時に HEAD + Block N のマージが必要になり CPU 消費が増加する - 失活系列比率の計測: `prometheus_tsdb_head_stale_series{} / prometheus_tsdb_head_series{}`(v3.6.0+) - **既知バグ #18379 あり。本番導入は修正後(ETA v3.12.0–v3.13.0)を推奨** Reddit 本番実験では失活系列比率 0.4–0.7 の環境で閾値 0.4 に設定し効果を確認。→ 詳細は [[Prometheusシリーズチャーン]] 参照。 ## VictoriaMetricsとの比較（Jorijn 2025） [[@2025__Jorijn-Blog__VictoriaMetrics vs Prometheus]] は、実務家視点で両システムを比較した記事。Prometheusを選ぶべき条件として以下を挙げる: - **既存安定スタック**: 移行コストが便益を上回る（"boring is best"） - **[[CNCF]]統治が必須**: Prometheusは[[CNCF]]卒業プロジェクト（Grafana Labs・Red Hat・G-Research等の多企業体制） - **PromQL移植性が必須**: 複数バックエンド間でクエリを共有する環境 Prometheusの弱点として指摘されている点: - **高カーディナリティ時のOOM**: グレースフルデグラデーションなし。クラッシュまで段階的な劣化がない - 英国法務省（2024年4月）: 大規模WALリプレイが再起動ループ→3時間21分監視喪失 - Cloudflare: 49億シリーズ規模でカスタムパッチが必須 - PingCAP: 768GB RAM単一インスタンスでもOOM・WALリプレイ40分超 → [[Prometheusシリーズチャーン]] / [[VictoriaMetrics]]参照 ## LLM エージェントのツールとしての Prometheus(Vitui & Chen 2026) [[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]] は、[[Red Hat OpenShift]] 上の [[ReAct]] ベース LLM エージェントに、Prometheus をデータソースとする 3 種類のカスタムツールを統合した: メトリクス名一覧取得(T7)、指定期間のメトリクス値・タイムスタンプ取得(T8)、瞬間変化率(irate)のプロット生成(T9)。複数ツールの連鎖(サービス発見 → 時刻範囲計算 → Prometheus クエリ → 出力整形)を要する Advanced Reasoning タスク(Q-16, Q-17, Q-19, Q-20)は、単発ツール呼び出しの Simple Reasoning タスクよりモデル間の精度差が大きく現れる領域として報告された。 ## 関連 - ソース: [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]] / [[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale]] / [[@2017__SREcon17 Europe__Monitoring Cloudflare's Planet-Scale Edge Network]] / [[@2025__VLDB__Approximation-First Timeseries Monitoring Query At Scale]] / [[@2024__IEEE CLOUD__Enabling Programmable Metric Flows]] / [[@2022__Cloudflare-Blog__Monitoring-our-Monitoring]] / [[@2026__SREcon26Americas__Unlock High-Frequency Deployments without Blowing Up Prometheus]] / [[@2025__Jorijn-Blog__VictoriaMetrics vs Prometheus]] / [[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]] - 関連システム: [[VictoriaMetrics]] / [[PromSketch]] / [[PMF]] / [[pint]] - 概念: [[時系列データベース]] / [[テレメトリ]] / [[Prometheusルールリント]] / [[Prometheusシリーズチャーン]] / [[Prometheus TSDB]] / [[MetricsQL]]