Prometheusの特徴とアーキテクチャ
Prometheusとは？
Prometheusは、SoundCloudという海外の音楽関連サービスのエンジニアが開発した監視システムである。もともとKubernetesの前身であるGoogle社内のBorgというシステムがあり、それを監視するためのソフトウェアとしてBorgmonがGoogle社内で作られた。そのBorgmonを参考にしてオープンソースとして公開されたものがPrometheusである。
Prometheusは時系列データベースを採用したPull型のデータモデルを持ち、Service Discoveryという機能によって対象を自動的に監視する。また、PromQLという専用クエリ言語があり、これを使って簡単で柔軟なクエリを実行できる。さらに、さまざまなExporterが用意されている。いわゆる監視エージェントであり、これを使うことでサーバーだけでなく、特定のソフトウェアやサービスなど多様なものを監視できる。
Prometheusの何がすごいのか？
Prometheusの何がすごいのかについてはいろいろ話せるが、まずは以下を見てほしい。これは2016年のPromConという海外カンファレンスで発表された内容からの引用である。
DreamHackのシステム監視にPrometheusが使用された（出典）
これによると、DreamHackというゲーム関連イベントのバックグラウンドシステムを監視するためにPrometheusが利用されたという。このときは10,000台のコンピュータと500台のスイッチを監視したことで非常に有名になった。これは2016年の話であり、その時点ですでにこれだけのコンピュータを監視できていた。現在はさらにアップデートされているはずなので、パフォーマンスはより高くなっていると期待できる。
Prometheusアーキテクチャ
Prometheusのドキュメントを見ると、Prometheusアーキテクチャとして次の図が掲載されている。
Prometheusアーキテクチャ
この図は大きく6つに分けられる。
- Prometheus Server、つまりPrometheus本体
- Service Discovery
- Exporterという監視エージェント
- 警告機能を扱うAlert
- クエリ言語であるPromQL
- 可視化機能であるVisualization
それぞれ説明していく。
Prometheus Server
Prometheus Serverは前述したとおりPrometheus本体である。このPrometheus Server自体は、各監視対象からMetricsを収集したり、収集したMetricsに対してクエリを実行してMetrics情報を参照したり、内部で定期的にクエリを自動実行して警告を管理したりする役割を担う。
また、このPrometheus Serverをはじめ、Prometheusエコシステムに含まれるソフトウェアの多くはシングルバイナリで動作する。つまり、1つのバイナリをダウンロードするだけで動作できる。たとえばZabbixを利用するには、まずZabbixサーバーのインストール手順が発生し、それだけでなくMySQLを用意したり周辺設定を行ったりする必要があり、意外と手間がかかることがある。Prometheus Serverは、本当にバイナリを1つ実行するだけで動作させられるという特徴がある。
Service Discovery
Service Discoveryは、監視対象の情報を自動で取得する仕組みである。これを使うことで、クラウドプラットフォームや特定ソフトウェアなどのAPIを定期的に呼び出し、そこに登録されたインスタンス情報を収集する。
たとえば、あるクラウドサービスにサーバーが3台あり、そのサーバー名とIPアドレス情報をAPI経由で取得して、それをターゲット情報としてPrometheusに渡す。その後、サービスをスケールする必要があり、サーバーを3台追加したとする。これでサーバーは6台になる。この3台が追加されたこともAPIを定期的に呼び出すことで把握できるため、自動的に追加される。そして過負荷状態が終わり、サーバーを3台削除すると、再び3台に戻る。この場合もAPIの定期呼び出しから3台減ったという情報を取得できるため、自動的にターゲットを3台減らす動作を行う。この仕組みによって、これまで1つずつ手動で登録したり専用ファイルに登録したりしていた面倒な作業を自動化できる。
これが嬉しい理由は、現代のクラウドサービスやマイクロサービスと呼ばれるシステムを利用する場合、それぞれのインスタンス情報が非常に頻繁に変わるためである。今ではDockerやKubernetesといったコンテナが当然のものになっている。コンテナは長期間使い続けることもあるが、作成されて消え、また作成されることを繰り返す前提にもなっている。Service Discoveryを使うと、このような場合にもより簡単に対応できる。
Service DiscoveryがサポートするプラットフォームはAzure、AWS EC2、GCP GCE、OpenStackであり、もちろんKubernetesにも対応している。その他にも拡張を通じて別のプラットフォームから情報を取得できる。
Exporter
Exporterはいわゆる監視エージェントである。Exporterは監視対象からMetricsを収集してPrometheusに公開する。たとえばNginxのCPU使用率やRequest数などの情報は取得できるが、それぞれの形式をPrometheusは知らない。毎回その形式をPrometheus側で保守するのは難しい。そこで、このExporterを間に置くことで、ExporterがNginxやApacheなど対象システムからMetrics情報を取得する。取得方法はAPIであったり、直接特定のコマンドを実行したり、さまざまである。そうして取得したMetrics情報をPrometheusが読める形に変換するのがExporterという仕組みである。
Exporterは現在600種類以上という非常に多い数がある。カスタムで作ることもできるため、他のシステムではできなかった監視も簡単に実現できる。
Alerting
他の監視システムでは、警告メカニズムが標準で提供されていて当然だと考えられる。しかし残念ながらPrometheus自体には警告機能はない。そのためAlertManagerというコンポーネントを使用する。これはPrometheusコミュニティによって保守されているソフトウェアの一つだが、このAlertManagerは優れている。たとえば複数のPrometheusをデプロイし、警告処理を1つのAlertManagerで行う場合、自動で重複を除去する。「この警告とこの警告は同じ警告なので2つ出す必要はない」と判断して1つにしたり、複数の類似した警告をまとめて「このような障害が発生した」という形にグループ化したり、Prometheus Metricsのラベルを見て「これはAチーム、これはBチーム」という形でルーティングしたりできる。このような柔軟な構造でAlertManagerは動作する。
つまり、警報に関する柔軟な仕組みをPrometheus本体に作るのではなく、あえて分離することで、それぞれのライフサイクルを隔離し、AlertManagerは警報についてより専門的かつ迅速に開発を進められるようにコンポーネントが分かれている。
PromQL
PromQLはPrometheus Query Languageの略である。これは後で詳しく紹介するが、非常に簡単で時系列データに合った形で使用できる。PromQLの優れている点は、Metricsラベルでフィルタリングできることである。たとえばインスタンス名、IPアドレス、クラウドプラットフォームのリージョンなどをラベルとして使用できる。Metricsに登録されたラベルでフィルタリングできるため、非常に直感的である。
またPromQLは、フィルタリングだけでなく、関数を使った集計や警告の実行などにも幅広く使われている。PromQLはPrometheusを利用するときに必ず知っておくべき要素の一つである。
Visualization
Prometheusで可視化を行う方法は2つある。1つはPrometheusに備わっているWeb UIを使う方法である。Reactで作られたWeb UIがPrometheus本体に提供されており、Prometheusエンドポイントへアクセスして簡単なMetricsクエリを実行できる。たとえば次の図はPrometheusを実行しているサーバーのメモリ使用率を示している。このような簡単なMetricsであれば、このWeb UIでも確認できる。
Prometheus Web UIを使用したVisualization
しかし、より複雑なパネルやグラフを保存したい場合は、このWeb UIでは不足するため、より専門的で高機能なGrafanaを使用できる。GrafanaはPrometheusをサポートしており、標準データソースとしてPrometheusを選択できる。下の図はNodeExporterというサーバー監視用Exporterの情報を表示したダッシュボードであり、このようにかなり豊富なダッシュボードを作成できる。
Grafanaを使用したVisualization
Grafanaと先ほどのWeb UIの2つがあるが、Grafanaの方が機能が多いからこれだけを使えばよい、というわけではない。よく見るダッシュボードや保存しておきたいダッシュボードはGrafanaを使い、その場でインスタンスに対して発行したいクエリ、たとえば障害発生時に調査のためいろいろなクエリを作って発行する場合には、Prometheus標準のWeb UIを活用するとよい。
Prometheusコンポーネントまとめ
このようにPrometheusのアーキテクチャは主に6つの構成要素で構成される。こう見ると意外とシンプルだと思う。Service DiscoveryはPrometheus自体の機能なので、Prometheus Serverを使えば最小限の監視が可能である。
次は
次は、Prometheusを使ううえでぜひ知っておきたい話として、CNCFという組織との関係やObservabilityについて扱う。