Prometheusとは - 時系列データベースによるメトリクス監視
このセクションでは、監視・可観測性の世界に登場するPrometheusについて解説します。Prometheusの基本的な考え方、アーキテクチャ、そしてなぜ多くの組織で採用されているのかという背景を理解することで、その後の詳細な設定や運用についても理解しやすくなります。
Prometheusの基本概念
Prometheusは、オープンソースの時系列データベース兼監視システムです。簡単に言うと、システムやアプリケーションのいろいろな数値データを自動的に集めて、時間経過とともに保存しておく仕組みです。
時系列データというのは、「時間ごとに測定された数値」のこと。たとえば、サーバーのCPU使用率が「9時0分は30%、9時1分は45%、9時2分は35%」といった具合に、時間ごとに変わっていく値です。こうした数値を効率的に保存・検索するために設計されているのがPrometheusです。
従来の監視ツールの多くは、エージェントがサーバーに常駐して、監視側に向かって「今のCPU使用率は45%です」と送りつける「プッシュ型」という方式を採用していました。一方、Prometheusは「プル型」という異なるアプローチを採用しています。Prometheus側から「今のメトリクスをちょうだい」と定期的に要求し、各サーバーやアプリケーション側で公開した /metrics というエンドポイントからデータを取得します。このエンドポイントには、Node Exporterなどのツールを使用するか、アプリケーション内にPrometheusクライアントライブラリを組み込んで実装します。
このプル型のアプローチには大きなメリットがあります。サーバー側の実装がシンプルになり、ネットワークの問題で送信に失敗することを心配する必要がありません。また、複雑な認証や暗号化の設定も不要になることが多いです。
ラベルベースのデータモデル
Prometheusの特徴的な点として、メトリクスにラベルという概念があります。ラベルというのは、メトリクスに付与される属性タグのようなものです。
たとえば、CPUの使用率を測定する cpu_usage_percent というメトリクスがあるとします。このメトリクスに対して、instance="server1" や instance="server2" というラベルを付けることで、どのサーバーのCPU使用率か区別します。さらに cpu="0" や cpu="1" というラベルを付けると、どのCPUコアなのかも分かるようになります。
cpu_usage_percent{instance="server1", cpu="0"} = 35
cpu_usage_percent{instance="server1", cpu="1"} = 42
cpu_usage_percent{instance="server2", cpu="0"} = 28
cpu_usage_percent{instance="server2", cpu="1"} = 31このように、同じメトリクス名でも、ラベルの値が異なれば別々のデータとして保存されます。こうしたデータモデルを「マルチディメンショナル」と呼びます。つまり、複数の側面からデータを分析できるという意味です。あとで「server1のCPU0の使用率だけ見たい」「全体のCPU使用率の平均を計算したい」といった柔軟な分析が可能になるわけです。
メトリクス名は英字とアンダースコアで始まり、アルファベット・数字・アンダースコアのみで構成されます。例えば http_requests_total 、cpu_usage_percent といった具合です。
Prometheusの3つの主要要素
Prometheusで監視を実現するには、3つの重要なコンポーネントが連携します。
Prometheus Server（監視サーバー）
Prometheus Server は、監視の中心となるコンポーネントです。このサーバーは、以下の2つの重要な機能を担っています。
スクレイパー機能: 定期的に各種サーバーやアプリケーションの /metrics エンドポイントにアクセスして、メトリクスデータを取得します。この取得間隔は、通常は15秒や30秒などに設定でき、カスタマイズできます。
時系列データベース（TSDB）: 取得したメトリクスを自動的に保存します。メモリやディスクに効率的に時系列データを格納し、後でPromQLという言語でクエリできるようにしておきます。デフォルトでは取得したデータは15日間保持されますが、設定で変更することも可能です。
Exporter（メトリクス公開）
Exporter とは、システムやアプリケーションのメトリクスをPrometheusが読み取れる形式で公開するコンポーネントです。
例えば、LinuxサーバーのCPU、メモリ、ディスク使用量などのメトリクスを公開するには Node Exporter を使用します。Prometheusと同じ組織が提供している公式のエクスポーターで、多くの環境で活用されています。
アプリケーション自体にメトリクス公開の機能を組み込みたい場合は、言語別のPrometheusライブラリを使用します。Pythonなら prometheus_client 、Java なら micrometer というように、各プログラミング言語用の実装が提供されています。
AlertManager（アラート通知）
AlertManager は、Prometheus Server で検出されたアラート条件に基づいて、実際の通知処理を担当するコンポーネントです。メール、Slack、PagerDuty などのチャネルへ通知を振り分けます。
Prometheus Server 側で「CPUが90%を超えたらアラート」といったルールを定義しておくと、その条件を満たした際に AlertManager に通知が送られます。AlertManager は、そのアラートを適切なチャネル（メール、Slack、PagerDuty など）に振り分けて、実際に人や他のシステムに通知を送ります。
適用シーン別ガイド
インフラストラクチャ監視
サーバー、ネットワーク、ストレージなどのインフラ要素を監視する場合、Node Exporter を使用するのが一般的です。CPUやメモリ、ディスクI/O、ネットワークトラフィックなど、多くのメトリクスが自動的に収集できます。
こうした監視は、サーバーのヘルスチェックやキャパシティプランニングに役立ちます。例えば、ディスク使用量が増加していく傾向を見つけたら、事前にディスク容量を拡張する計画が立てられます。
アプリケーション監視
Web API やバッチ処理などのアプリケーションを監視する場合は、アプリケーション内に Prometheus クライアントライブラリを組み込んでメトリクスを計測します。
リクエスト数、レスポンス時間の分布、エラー率など、アプリケーション固有のメトリクスを計測することで、ユーザー体験に直結する問題を早期に発見できます。
複合的な監視
実際の運用では、インフラとアプリケーションの両方のメトリクスを同時に収集し、相関分析することが多いです。「APIのレスポンスタイムが遅くなった」という問題が、「同じタイミングでサーバーのディスクI/O が増加していた」ということに気づくといった、複合的な分析が可能になります。
Prometheusを選ぶメリット
Prometheus を採用するメリットはいくつかあります。
第一に、オープンソースであり、商用サポートが不要です。コストをかけずに導入でき、必要に応じて内部の動作をカスタマイズできる柔軟性があります。
第二に、メトリクスの保存と検索がシンプルです。多くの監視ツールでは複雑な集約処理が必要ですが、Prometheus のラベルベースのモデルなら、柔軟かつ効率的なデータ分析ができます。
第三に、Grafana などの可視化ツールとの連携が充実しています。Prometheus で収集したメトリクスを、Grafana で美しいダッシュボードとして表現することが事実上の標準になっています。
第四に、Kubernetes やクラウドネイティブな環境との相性が非常に良いことです。コンテナベースのシステムでは、動的にサーバーやコンテナが立ち上がり・消滅しますが、Prometheus の自動ディスカバリー機能がこうした環境に適応しやすい設計になっています。
次のステップ
ここまで、Prometheus の基本的な考え方と全体像を理解しました。これで、実際の導入に向けた詳細な学習に進む準備ができています。
次のパート「Part 1-1. Prometheusアーキテクチャ詳解」では、各コンポーネントの詳細な機能と、どのように連携して監視を実現しているのかについてさらに深掘りします。