【Prometheus入門①】Prometheusとは？

この記事はモニタリング基盤に興味がある方、Prometheusをこれから触ってみたい方に向けて、Prometheusの概要・特徴・アーキテクチャ、そして採用される理由を体系的にまとめたものです。

Prometheus とは？

Prometheus（プロメテウス） は、CNCF（Cloud Native Computing Foundation）にホストされている OSS のモニタリング＆アラーティングプラットフォームです。もともとはSoundCloud社内の業務課題を解決するために開発されましたが、2016 年に CNCF に寄贈された後、Kubernetesに続き2番目にGraduatedステータスを獲得しました。

現在ではKubernetesをはじめとするクラウドネイティブ環境のデファクトスタンダードとして広く利用され、AWS、GCP、Azure など主要クラウドでも公式インテグレーションが用意されています。

ポイント

  • コンテナ／マイクロサービスとの親和性が高い
  • ラベルベースの柔軟な時系列データモデル
  • 強力なクエリ言語 PromQL と豊富な可視化手段
  • CNCF Graduated & OSS ＝ ベンダーロックインなし

Prometheus が活躍するユースケース

ユースケース具体例
コンテナオーケストレーションKubernetes/ECSのクラスター・Pod監視
マイクロサービスHTTP APIのレイテンシ・エラーレート計測、SLO 監視
インフラ監視Node Exporterによるサーバリソース監視、外形監視（Blackbox Exporter）
バッチ／ジョブPushgatewayでジョブ終了時にメトリクスを Pushし履歴を残す

Prometheusの4つの主要特徴

ラベルによる柔軟なメトリクス管理

Prometheus はすべての監視データをメトリクスとして扱い、メトリクス名とラベルの組み合わせが時系列データのKey として機能します。このKeyに対して時系列のValueが保存され、後にクエリや集計の対象となります。

メトリクス名とラベルの例

http_requests_total{method="POST", handler="/api/upload", status="500"} 42
要素説明
メトリクス名http_requests_total = HTTPリクエスト数（カウンター）を表すメトリクス
ラベルmethod="POST", handler="/api/upload", status="500"
Keyhttp_requests_total{method="POST", handler="/api/upload", status="500"}
Value42

このラベル機構により、メトリクスの粒度を自由に設計でき、後続の分析やアラートで柔軟な条件設定が可能になります。

PromQLによるクエリ — 専用クエリ言語

Prometheusのメトリクスを取得・集計・分析するためには、PromQL（Prometheus Query Language）を使用します。

PromQLは、メトリクスの時系列データに対して直感的かつ柔軟に操作を行えるよう設計された専用言語で、ダッシュボードでのグラフ表示だけでなく、アラートの条件式としても利用されます。

クエリ例

http_requests_total{handler="/api/upload"}

このクエリは、メトリクス名http_requests_totalに対して、ラベルhandlerが"/api/upload"であるものを抽出します。

クエリ意味
http_requests_totalHTTPリクエスト数を表すメトリクスを対象
{handler="/api/upload"}ラベルhandlerが/api/uploadのものに限定

このようにPromQLでは、SQLに似た簡潔な構文で強力な条件指定が可能です。

さらに次のような関数も組み合わせることで、時系列データの変化量や平均値を扱えます。

rate(http_requests_total[5m])
sum(rate(http_requests_total[1m])) by (method)
avg_over_time(http_requests_total[10m])
up == 0

これらはリアルタイムな可視化やアラート検知に活用されます。
（PromQLの関数について別途記事にまとめる予定です）

Pull型によるメトリクス収集

PrometheusはPullモデルを採用しており、監視対象から定期的にメトリクスを取得（スクレイプ）します。監視対象が外部にPushするのではなく、Prometheus側から能動的に収集しに行くアーキテクチャです。

これにより、スクレイプ間隔やターゲット管理をPrometheus側で統制でき、監視の一貫性が確保されます。

Service Discovery（サービス検出機能）

動的環境に対応するため、PrometheusはService Discover機能を備えています。これにより、インフラのスケールイン・スケールアウトに応じて監視対象を自動で検出・更新できます。

対応例：

  • Kubernetes (Endpoints/Pod/Service)
  • EC2/Auto Scaling Group
  • Consul/Etcdほか

動的スケール環境でもPrometheusの設定ファイルに監視対象の固定IPを書く必要がなく、監視対象を追従できます。

Pushgatewayを使ったPush型収集

通常、Prometheusは監視対象からPull型でメトリクスを収集しますが、バッチジョブなど短時間で終了するプロセスではPull型が適していない場合があります。

そのようなケースに対応するため、Pushgatewayを利用してジョブ側からメトリクスをPushすることができます。

Prometheusのアーキテクチャ

Prometheus エコシステムは複数のコンポーネントで構成されており、その多くはオプションとして提供されています。

コンポーネント役割
Prometheus Server時系列データのスクレイプ、保存、クエリ処理をする
Pushgateway短命なジョブからのメトリクスをPushさせるためのゲートウェイ（通常のPull型とは異なる）
ExporterNode/アプリ/ミドルウェアなどのメトリクスを HTTPで公開する専用エージェント
Alertmanagerアラートルール評価結果を受け取り、重複抑止・ルーティング・通知をする
GrafanaPrometheusをデータソースとしてダッシュボードを作成する

これらのコンポーネントを組み合わせることで、柔軟かつ強力なモニタリング基盤を構築することが可能です。

アーキテクチャ

参考サイト：https://prometheus.io/docs/introduction/overview

5. Prometheusが選ばれる理由

理由説明
クラウドネイティブ適合Kubernetes/サービスメッシュとシームレス統合
柔軟なデータモデルラベルで多次元分析が可能、メトリクス設計の自由度が高い
PromQL の表現力集計関数・演算子が豊富、アラート定義にもそのまま利用
高スケーラビリティ単一ノードでも高性能、（Thanos/Cortexで水平分割も容易？）
豊富なエコシステム公式Exporter 200+、Grafanaダッシュボード多数、OSSで拡張自在

6. まとめ & 次回予告

Prometheusは「スケーラブルで柔軟、クラウドネイティブに最適化されたモニタリング基盤」 を構築するうえで、最も強力な選択肢の一つです。

次回は実際にKubernetesクラスターへPrometheusをデプロイし、メトリクス収集からGrafanaでのダッシュボード作成までをハンズオン形式で進めていきます。

続編: 【Prometheus入門②】Kubernetesで始めるPrometheusハンズオン（予定。。。）

コメント

タイトルとURLをコピーしました