監視の仕組みをPrometheusで理解する

こんにちは、札幌のヨシエです。
最近改めて触り始めたPrometheusに関して構築しながら学習した内容をまとめた記事になります。
網羅的な解説ではなく、手を動かす中で詰まった点や、後になって理解が変わった点も含めて書いていきます。

Prometheusとは

『Prometheus』という名前を聞いたことがある方は多いかもしれませんが、このセクションではPrometheus自体の概要を書いてみます。

監視ツールとしての性格が面白く、これまでの監視基盤はざっくりといえば監視手法から発報方法までが1セットで提供されているものが多かったです。
一方でPrometheusは監視手法や発報方法が各コンポーネントに分離されており、利用する組織にとって不要だと思われるコンポーネントは追加しないという選択ができるツールになっています。

不要なコンポーネントを導入しないという選択ができることで、稼働するプロセスや待受ポートを必要最小限に抑えられます。
その結果、障害が発生した際に確認すべき箇所が局所化しやすくなり、トラブルシューティングの効率化にもつながります。

セキュリティ観点でも、そもそも使用しない機能を動かさない構成にできるため、アタックサーフェス(攻撃対象領域)を小さく保つことができます。
これにより、不要な機能に起因する脆弱性のリスクを低減できる点もメリットの1つだと考えられます。

Push型とPull型のお話

監視基盤が監視対象から数値(メトリクス)を取得する方法は、大きく分けてPush型とPull型の2つに分かれます。

Pull型は、監視基盤側が定期的に各サーバーに対してリクエストを行い、メトリクスを取得しにいく方式です。
リクエストに対する応答の有無によって死活監視も兼ねられる点が特徴です。「メトリクスを取得できない=対象が落ちている可能性を示す」と判断しやすくなります。

Push型は、監視対象のサーバー側からメトリクスを監視基盤に向けて送信する方式です。
クラウドや仮想環境のようにサーバー台数の増減(スケールアウト/イン)が行いやすい環境では、監視対象が増えても監視基盤側で対象を都度登録する必要がありません。
これはサーバー側が自発的にデータを送ってくれるため、管理がしやすいというメリットがあります。

PrometheusではExporterを使えばPull型、Pushgatewayを使えばPush型というように、利用するコンポーネントに応じて収集方式を選択できます。

バッチ処理のようなライフサイクルが短いサービスはPushgateway、常時稼働しているサーバーにExporterを利用するというように監視対象の性質に合わせて使い分けることも可能です。

他の監視ツールとは何が違うのか

監視ツールは非常に多岐に渡るため、他の監視ツールと違う一例を書き出してみます。

※現時点での主観による記載のため、詳細は各社公式サイトの確認をお願いします。

上記のような特徴がある中、使用される監視ツールはインフラ基盤や監視項目に応じて選択される形になると思われます。
これは監視ツールの利用にあたり、発生する金額的コストが安価なもの、既に同組織内で導入済実績があることや同じ役割のシステムに対して監視手法の踏襲を含めた観点で選択されるものがあります。

Prometheusの主要なコンポーネント

冒頭で記載したようにPrometheus自体は様々なコンポーネントを組み合わせることで監視を実現できます。
このコンポーネント群より、主要なコンポーネントとして扱われるものを整理します。

Prometheus Server

名称のままですが、監視対象からメトリクスを取得・保存し、確認できるようにするコンポーネントです。
今回は便宜上Prometheus Serverと一括りに記載していますが、内部的には複数の要素が組み合わさって動作しています。
具体的には監視対象からメトリクスを取得しにいくRetrieval、取得したメトリクスを保存するTSDB、保存されたメトリクスを照会するためのHTTP Serverという3つです。

ちなみにTSDBは既に実装されている仕組みを使うことで外部のストレージシステムと連携させることが可能になっています。
これにより、ローカルディスクの容量制限を超えた長期保存や、3rdPartyと組み合わせた可用性向上の構成を取ることもできます。

Exporter

Exporterは、監視対象が持つ様々な形式のデータをPrometheusが解釈できる形式に変換した上で、/metricsというHTTPエンドポイントとして展開する役割を持っております。
このExporterはメトリクスを公開するところまでが役割で、Prometheus Serverはこのメトリクス値を取得して監視をおこなっております。

Prometheus Serverはscrape_intervalで設定した間隔ごとに、対象のExporterが公開している/metricsエンドポイントへ定期的にHTTPリクエストを行います。
そして、そのレスポンスとしてメトリクスを取得しにいきます。この一連の動作のことを Scrapeと呼びます。

一例としてPrometheusから監視対象のEC2サーバーのメトリクスを監視する場合、以下のようにそれぞれのサーバーで作業が必要になります。

• EC2サーバー：NodeExporterのインストール(OSやハードウェアのメトリクスを取得し、/metricsエンドポイントとして公開するツール)
• Prometheus Server:Prometheusサーバー側で監視対象(Exporter)のエンドポイント情報とScrapeの実行間隔(scrape_interval)を指定

Pushgateway

PushgatewayはExporterと異なり、一時的にリソースが起動して処理が完了するとリソース自体が終了してしまうサービスを監視することを目的としたコンポーネントです。
LambdaやAWS Batchのようなサービスが代表例になります。

Exporterのケースでは、常時起動しているサーバーに対してPrometheus Serverが定期的にメトリクスを取りに行くことができました。
しかし、LambdaやAWS Batchのような一時的なリソースは、Prometheus Serverがメトリクスを取得しようとした時点で既に終了してしまっている可能性があります。
そのため、これらの監視対象にはPull型を使うことができません。
そこでPushgatewayを介して、リソース側からメトリクスを能動的に送りつける(Push)という構成を取ります。

一例としてPrometheusでLambda関数を監視する場合を考えてみます。実装に応じて挙動が変化するため、あくまで一例となります。

• Lambda関数：処理の終了間際にPrometheusのライブラリを使い、処理件数や実行時間、成功/失敗を表すメトリクスをコード内で算出する。算出したメトリクスは、Pushgatewayに対して送信する処理を実装する
• Pushgateway：Lambda関数から送信されたメトリクスを保持し、/metricsエンドポイントとして公開する
• Prometheus Server：scrape_intervalで設定した間隔ごとにPushgatewayの/metricsエンドポイントへリクエストを行い、保持されているメトリクスを取得する

Alertmanager

Alertmanagerは、Prometheusから受け取ったアラートを予め設定されている通知先へアラート発報を行ってくれるコンポーネントになります。

ただ単純にアラートを右から左へ転送しているだけではなく、グルーピングとルーティングという2つの仕組みを持っているのがAlertmanagerの特徴です。

グルーピングは、似た性質を持つ複数のアラートを1つの通知にまとめる機能です。同じ障害が原因で複数のサーバーやサービスから同時にアラートが発火した場合、それぞれを個別に通知してしまうと通知が大量に届いてしまい、本来把握したい問題の全体像が掴みにくくなります。Alertmanagerではgroup_byで指定したラベル(例:alertnameやclusterなど)を基準にアラートをグルーピングし、まとめて1通の通知として送ることができます。

ルーティングは、アラートが持つラベルの内容に応じて通知先を振り分ける機能です。設定ファイル内にツリー構造(ルーティングツリー)を定義しておくことで、ラベルの条件に一致したアラートを対応する通知先(Slack、メール、PagerDutyなど)へ振り分けることができます。例えば「重要度が高いアラートは特定のチームへ、特定のサービスに関するアラートは担当チームのチャンネルへ」といったように、チームや重要度に応じて通知先を柔軟に分けることが可能です。

まとめ

今回はPrometheusの主要なコンポーネント(Prometheus Server、Exporter、Pushgateway、Alertmanager)がそれぞれどのような役割を持ち、どう組み合わさって監視を実現しているかを整理しました。コンポーネントが分離されているからこそ、監視対象の性質(常時稼働かエフェメラルか)に応じて構成を選べる点がPrometheusらしさだと感じています。今後はは実際の構築で詰まった点を書いていく予定です。