ログやモニタリングのツールの多くは、データを送り込むものです。それに対して Prometheus は、pull することを中心に構築されています。スケジュールに従って、監視している対象に自ら出向き、現在の数値を尋ねます。この 1 つの設計上の決定が、デプロイと設定の方法のほとんどすべてを形作っており、このガイドでは、そこから導かれるアーキテクチャを説明します。

スクレイピング：push ではなく pull

Prometheus は、監視しているすべてのシステムに定期的に HTTP リクエストを送り、そのシステムの現在のメトリクス値のスナップショットを読み取ります。Prometheus はこれをスクレイピングと呼び、スクレイプされる各対象をターゲットと呼びます。スクレイプはその瞬間の値だけを運び、ペイロードに履歴はありません。間隔をおいて行われた一連のスクレイプを履歴に変えるのが Prometheus です。

pull モデルには実際的な結果があります。Prometheus が監視する対象は、Prometheus が理解できる形式で現在の値を返す HTTP エンドポイント（慣習的には /metrics）を公開する必要があります。Prometheus が、あらゆる可能なソースがデータを押し込んでくるための着信リスナーを必要とするのではありません。

ターゲット：計装されたアプリと exporter

ターゲットは、次の 2 つのカテゴリのどちらかに入ります。

• 直接計装されたアプリケーション。 Prometheus の公式クライアントライブラリの 1 つを使う、自分自身のサービスが、自分のメトリクスを追跡し、/metrics エンドポイントでネイティブに公開します。
• Exporter：Prometheus のメトリクスを自分では公開しない（またはできない）すべてのもののためのものです。データベース、Linux ホスト、ネットワーク機器などです。exporter は、監視対象の隣で動作する小さなプロセスで、そのネイティブな統計を Prometheus の形式に変換します。ホストレベルのメトリクス（CPU、メモリ、ディスク、ネットワーク）には node_exporter、コンテナごとのメトリクスには cAdvisor が、最も広く使われているものの 2 つです。

公開形式は意図的にシンプルなテキストなので（次のガイドで説明します）、exporter を書くこと、あるいはクライアントライブラリなしで手作業でメトリクスを作ることさえ、Prometheus の公式サポートがないものでも現実的です。

ターゲットを見つける：静的な設定かサービスディスカバリーか

Prometheus には、スクレイプするターゲットのリストが必要です。少数の安定したホストなら、Prometheus の設定ファイルに手で列挙しても問題ありません。より大きいもの、またはより動的なもの、つまり増減するマシンやコンテナでは、手作業での維持はすぐに非現実的になります。代わりに Prometheus は、DNS、Kubernetes API サーバー、クラウドプロバイダーの API などのサービスディスカバリーの仕組みと統合し、環境が変化するのに合わせて、ターゲットのリストを自動的に構築し、継続的に更新します。

ストレージ：ローカルの時系列データベース

スクレイプされたサンプルは、Prometheus 自身のディスク上のローカル時系列データベース（TSDB）に保存されます。デフォルトでは、Prometheus は 15 日分のデータを保持します。これは設定可能なフラグ（--storage.tsdb.retention.time）で、厳格な制限ではありませんが、15 日あれば、実際のトラブルシューティングのほとんどで十分です。ほとんどのインシデントは、数分前から数時間前と比較され、数か月前と比較されることはまれだからです。長期保存や、多数の Prometheus サーバーにまたがる集中型ストアが必要な場合、Prometheus は、自身のローカル TSDB とは異なるトレードオフを持つ外部のストレージシステムにサンプルを転送（remote-write）するように設定することもできます。

コアサーバーを取り巻くもの

いくつかのコンポーネントが、典型的な構成を完成させます。

• Alertmanager は、Prometheus が発火中のアラートを渡す別個のコンポーネントです。重複排除、グルーピングを行い、設定したメール、Slack、PagerDuty などにルーティングし、「問題の検出」を「誰に、どのように通知するかの決定」から切り離します。
• Grafana（または Prometheus 自身に付属の Web UI、その他のツール）は、通常、データを探索して可視化するのに使うものです。Prometheus 自体は、メトリクスを確実に収集して保存することに焦点を当てており、ダッシュボードのレイヤーになることではありません。
• Prometheus のクエリ言語である PromQL は、Grafana のダッシュボードと Prometheus 自身のアラートルールの、両方が構築される基盤です。アラートとダッシュボードは、継ぎ合わされた 2 つの異なるシステムではなく、同じデータに対する同じクエリ言語の、2 つの利用者です。このシリーズの後のガイドで、データモデルと PromQL を直接説明します。

部品をまとめる

   ┌──────────────┐      HTTP でスクレイプ          ┌──────────────┐
   │  Prometheus  │ ───────────────────────────────▶ │  ターゲット    │
   │   サーバー    │                                    │ (/metrics)   │
   └──────┬───────┘                                    └──────────────┘
          │ サンプルを保存
          ▼
   ローカル TSDB（デフォルトの保持期間 15 日）
          │
   ┌──────┴───────────────┬───────────────────────┐
   ▼                       ▼                       ▼
発火中のアラートルール      PromQL クエリ            remote write
   │                    (Grafana、アドホック)       (任意、外部ストレージ)
   ▼
Alertmanager → メール / Slack / PagerDuty / ...

アラート、ダッシュボード、アドホックなデバッグなど、下流のすべてが、スクレイピングが満たすのと同じ TSDB から読み取ります。このシリーズの残りは、そこに実際に何が保存されるかから始まります。