製品プロフィール

Prometheus

SoundCloud → CNCF / メトリクス監視

時系列メトリクスを収集・保存し、PromQL で問い合わせる監視の定番。プル型で収集し、アラートも備える。

3つの要点
TL;DR
  1. 時系列メトリクスを収集・保存する監視の定番。
  2. プル型で収集し PromQL で柔軟に集計、アラートも可能。
  3. K8s 監視や SRE の標準。可視化は Grafana、ログ/トレースは対象外。

基本情報

仕様と立ち位置

Prometheus のロゴ
製品・技術の概要Prometheus時系列メトリクスを収集・保存し、PromQL で問い合わせる監視の定番。プル型で収集し、アラートも備える。
種別
メトリクス監視
提供元
SoundCloud → CNCF
ライセンス
オープンソースApache 2.0)
登場
2012年
最大の強み
プル型で収集がシンプルPromQL で柔軟な集計
代表的な用途
メトリクス監視/アラートKubernetes 監視 / SRE / オブザーバビリティ

選定ガイド

選定ポイント

採用する理由と、事前に受け入れるべきトレードオフを分けて確認します。

採用に向く条件

選ぶ理由

  1. プル型で収集がシンプル
  2. PromQL で柔軟な集計
  3. クラウドネイティブ/K8s の標準

事前に確認する条件

考慮すべき点

  1. 長期保存は別途(リモートストレージ)
  2. 可視化は別(→ Grafana)
  3. ログ/トレースは対象外

詳しい解説

もっと詳しく

どんなツールか

Prometheus は、システムのメトリクス(数値の指標)を収集・保存・監視するためのツールです。CPU 使用率やリクエスト数といった値を時系列で蓄え、状態の変化を追えるようにします。CNCF 傘下のオープンソースで、クラウドネイティブ監視の定番です。

「結局なに?」を一言でいえば、メトリクスを時系列で集めて監視する仕組みです。

横にスクロール

Prometheusがサービスディスカバリで対象を見つけてHTTPでメトリクスを収集し、HeadとWALから永続blockへ保存し、PromQLとrulesで評価してAlertmanagerへ警告を送る流れ
Prometheusは対象のアドレスを発見し、自ら定期的にメトリクスを取得してHeadへ追加しながらWALへ記録します。未確定データは再起動時にWALから復元され、約2時間のblockへ永続化・圧縮されます。問い合わせとrulesはPromQLを評価し、Alertmanagerは警告の集約・重複排除・抑制・通知経路を担当します。

特徴・仕組み

データは自前の時系列データベース(TSDB)に保存されます。各メトリクスは名前とラベル(key=value)の組で識別され、ラベルの掛け合わせで柔軟に切り分けられます。

収集方式は Pull 型が基本で、Prometheus 側が監視対象(ターゲット)へ定期的にアクセスし、公開されたメトリクスを取りに行きます。

scrape_configs:
  - job_name: app
    static_configs:
      - targets: ['localhost:9090']
  • エクスポータ: DB やミドルウェアなど自前で公開しない対象は、メトリクスを変換して公開する小さな仲介役(node_exporter 等)を挟む。
  • サービスディスカバリ: Kubernetes などと連携し、増減する対象を自動で見つける。動的環境に強い。
  • PromQL: 専用クエリ言語で集計・条件付けし、しきい値超過などのアラートを定義できる。発報は Alertmanager が重複排除・経路振り分けを担う。

得意・不得意

  • 時系列メトリクスの収集とアラートに強く、Kubernetes 環境で定番。
  • PromQL で柔軟に集計・条件付けができ、Pull+サービスディスカバリで動的環境に強い。
  • 反面、ログそのものの収集やリッチなダッシュボード作成は主目的ではない。長期保存や水平スケールは Thanos/Mimir 等を足す前提。高カーディナリティ(ラベル値の爆発)には注意が要る。

役割分担

レイヤー担当補足
メトリクス収集・保存PrometheusPull+TSDB+PromQL
可視化Grafanaダッシュボード表示
アラート発報Alertmanager重複排除・通知経路
ログ別基盤(Loki 等)Prometheus の範囲外

グラフでの「見える化」は Grafana と組み合わせるのが定番で、Prometheus が収集、Grafana が表示、という分担です。

使いどころ・注意点

カーディナリティ設計

ユーザー ID やリクエスト ID のような値をラベルに入れると時系列数が爆発し、メモリと性能を圧迫します。ラベルは有限の次元に絞り、識別子は入れないのが鉄則です。長期保存や大規模化は Thanos/Mimir を検討します。

総じて Prometheus は、Pull 型収集・ラベル付き TSDB・PromQL を軸に、クラウドネイティブ環境のメトリクス監視を担う標準ツールです。

実装・運用の視点

Prometheusを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

メトリクス監視/アラート

比較で見る軸

種別: メトリクス監視 / 提供元: SoundCloud → CNCF / ライセンス: オープンソース(Apache 2.0)

導入後に効く点

PromQL で柔軟な集計

先に潰すリスク

長期保存は別途(リモートストレージ)

数字・仕様の読み方
種別
メトリクス監視
提供元
SoundCloud → CNCF
ライセンス
オープンソース(Apache 2.0)
登場
2012年

判断チェックリスト

  • 自社の用途が「メトリクス監視/アラート / Kubernetes 監視」に近いか確認する。
  • 強みである「プル型で収集がシンプル」が本当に評価軸になるか確認する。
  • 注意点の「長期保存は別途(リモートストレージ)」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

メトリクス監視/アラートKubernetes 監視SRE / オブザーバビリティ

向いている用途

こんな用途に向く

メトリクス監視/アラートKubernetes 監視SRE / オブザーバビリティ
公式サイト