Prometheusとは

最近では、Prometheusが技術分野でのアプリケーション監視の標準になりつつあり、人気となっています。しかし、Prometheusとは正確には何ですか？この記事では、さまざまなサブトピックに触れて、すべての始まりからアーキテクチャ、監視の正確さまで、Prometheusについて解説していきたいと思います。 Prometheusと一緒に使用できるさまざまな統合ツールと、Prometheusがこれらのプラットフォームとアプリケーションを監視するための優れたツールである理由についても説明していきます。

まずは、基本的なPrometheusの外観が以下です。これはPrometheus ExpressionBrowserと呼ばれます。

ただし、Prometheusは通常、Grafanaと一緒に使用されます。 Grafanaは、Prometheusメトリックを取得し、監視を容易にする視覚化ツールです。多くの場合、多くの人々がPrometheusの監視について話すときは、以下のような可視化をしているはずです。

MetricFireはHosted　Prometheusプラットフォームです。したがって、Prometheusを自分でチェックしたい場合は、MetricFireの無料デモをご予約いただき、トライアルにサインアップしてください。メトリックをMetricFireプラットフォームに送信し、Grafanaダッシュボードで視覚化することができます。

Prometheusとは - 歴史

Prometheusは、当時使用していたメトリックと監視ツール（StatsDとGraphite）がコンテナなどの監視のニーズに十分ではないことを発見した後、オープンソースプロジェクトとして2012年にSoundCloudで開始されました。彼らは、監視ツールBorgmon（当時Googleで使用されていた）からインスピレーションを得て、監視目的に不可欠な特定のニーズを特定しました。

たとえば、多次元データモデル、操作の簡素化、スケーラブルなデータ収集、強力なクエリ言語が必要でした。彼らは、これらすべての機能を1つのツールにまとめるためにPrometheusを構築しました。結果として得られたツールは非常に成功だったため、2016年にKubernetesに続く2番目のインキュベーションプロジェクトとしてCloudNative ComputingFoundationに受け入れられました。

Prometheusとは - アーキテクチャ

Prometheusは複数のコンポーネントで構成されており、それぞれが特定の機能を提供し、Prometheusのより広範な監視および警告に不可欠です。これらのコンポーネントは次のとおりです。

Prometheusサーバー：

これはシステムの頭脳です。ノードから時系列データの形式でメトリックを収集し、それらを保存します。メトリックを収集するプロセスは、スクレイピングと呼ばれます。
Prometheusメトリックは時系列形式で保存されます。これは基本的に、連続する等間隔の時点（通常はミリ秒単位）で取得された一連のデータポイントです。メトリックは、メトリック名、またはメトリック名とラベルと呼ばれるオプションのキーと値のペアの組み合わせを使用して、一意に識別および照会できます。ラベルを使用すると、メトリック全体とは別に測定するメトリックの特定の特性を区別または集約できます。これにより、メトリック名とラベルの組み合わせによって識別されるまったく新しい時系列が作成されます。

たとえば、アプリケーション内のさまざまなページのhttpリクエストの数をパスに従って追跡する方法が必要だとします。これを行う1つの方法は、それぞれが各パスに対応する複数のメトリックを作成することです。たとえば、http_requests_login_total、http_requests_logout_total、http_requests_adduser_total、http_requests_comment_totalは、それぞれログインページ、ログアウトページ、addUserページ、コメントページへのhttpリクエストを追跡します。ただし、アプリケーションからのhttpリクエストの総数をクエリする必要がある状況では、アプリ内の各パスを把握し、それらのすべてのメトリックをクエリする必要があるため、これは面倒になります。ただし、ラベルを使用すると、http_requests_totalなどの単一のメトリックを設定し、それに「パス」ラベルを追加できます（例：http_requests_total {path = "/ login"}）。これにより、クエリから「パス」ラベルを省略するだけでリクエストの総数をクエリしたり、特定のページへのパスを上記の形式で追加するだけで特定のページへのリクエストをクエリしたりできます。

Prometheusサーバーへのクエリの詳細については、こちらのPromQLの概要をご覧ください。

Prometheusサーバーは、アプリケーションがメトリックをプッシュするのを受動的に待機するGraphiteのような他のツールとは対照的に、監視するアプリケーションからメトリックをアクティブにプル（スクレイプ）します（スクレイプ間隔）。このモデルは、Prometheusサーバーがすべての面倒な作業を行うため、クライアントのほとんどの作業負荷を軽減します。彼らがしなければならないのは、Prometheusサーバーがアクセスできる方法でメトリックを公開することだけです。これを行うには、HTTPエンドポイント（通常は/ metrics）を公開します。これにより、メトリックの完全なリスト（ラベルセットが付属）とその値が返されます。

クライアントライブラリとエクスポーター：

先ほど、クライアントはPrometheusのメトリックをスクレイプするために公開する必要があると述べましたが、このデータはPrometheusが理解できる形式である必要があります。 Prometheusはデータを時系列形式で保存し、その形式のデータのみを受け入れます。したがって、Prometheusがスクレイプするには、クライアントによって公開されるメトリックがこの形式である必要があります。ただし、時系列形式のメトリックは通常、アプリケーションから発生することはありません。これらのタイプのメトリックを生成するインストルメンテーションは手動で追加する必要があります。メトリックをPrometheusに送信するアプリケーションのソースコードを制御および変更できるかどうかに応じて、2つの方法で実行できます。

数行のコードでソースコードを制御する場合、直接計測と呼ばれるプロセスでPrometheusのクライアントライブラリを使用して、必要なメトリックを定義および追加できます。クライアントライブラリは、簿記やスレッドセーフなどの重要な詳細をすべて処理し、Prometheusが直接スクレイピングできる形式でメトリックを送信するため、ユーザーはほとんど何もする必要がありません。ほとんどのライブラリは、ランタイム環境と使用されているライブラリに応じて、CPU使用率やガベージコレクション統計などの特定のメトリックも提供します。

ソースコードを制御できない場合、直接計測することはできません。たとえば、Linuxカーネルに関するいくつかのメトリック情報が必要だとします。カーネルにはメトリック情報を出力するための何らかのメカニズムがある可能性がありますが、このデータがPrometheusによって理解およびスクレイピングできる形式になる可能性はほとんどありません。ただし、この場合、Linuxカーネルのソースコードにアクセスできないため、クライアントライブラリを使用してメトリックをエクスポートすることはできません。この場合、エクスポーターを使用します。エクスポータは、関心のあるメトリックを持つアプリケーションと一緒にデプロイできるソフトウェアです。これらの詳細については、このMetricFireの記事を参照してください。

プッシュゲートウェイ：

寿命がスクレイプ間隔よりも短い短命またはバッチジョブがある場合はどうなりますか？つまり、Prometheusがメトリックを取得する前に、ジョブの実行が開始されて完了します。では、そのような仕事をするメトリクスをどのように収集しますか？プッシュゲートウェイです！　Prometheus Push Gatewayは、短期間のジョブがメトリックをPrometheusに公開できるようにするためだけに存在します。これらの種類のジョブは、Prometheusがスクレイピングするのに十分な長さではない可能性があるため、代わりに、メトリックキャッシュの一種として機能するプッシュゲートウェイにメトリックをプッシュして、Prometheusがスクレイピングできるように十分な長さを保持できます。プッシュゲートウェイの使用方法については、このMetricFireブログ記事を参照してください。

アラートマネージャー：

Prometheusはメトリック収集で最もよく知られていますが、アクションを促さなければ、そのすべてのデータは役に立たないでしょう。 Prometheus Alertmanagerを使用すると、収集されたメトリックに対して独自のアラートを定義できるため、収集されたデータに異常や不一致があった場合に通知を受けることができます。 Alertmanagerは、同じタイプの特定のアラートをグループ化し、他のアラートに基づいて特定のアラートを抑制するように構成できます。たとえば、クラスターがダウンしていることを示すアラートが発生します。これに基づいて、Alertmanagerは、そのクラスターからのその他すべてのアラート、および他の多くの高度なユースケースを抑制するように構成できます。利用可能なさまざまな統合を使用して、アラートマネージャーを使用して、SMS、電子メール、Slack、PagerDutyなどを介してアラートを直接送信できます。

視覚化：

Prometheusによって収集されたメトリックは、時系列データベースにローカルに保存されます。 Prometheus Query Language（PromQL）を使用すると、ユーザーは既存の時系列データをリアルタイムで選択して集計できます。この結果は、Prometheus Expression Browserにグラフまたは表形式のデータとして表示するか、HTTPAPIを使用して外部の視覚化統合を提供するために使用できます。 Prometheusの視覚化に最適な外部統合は、Grafanaです。

ただし、Prometheusはオープンソースプロジェクトのままであるため、これらの各コンポーネントを手動でセットアップし、上記の値を確実に提供するように保守する必要があります。 Prometheusのクラウドホストバージョンを試すには、今日MetricFireチームに連絡して無料デモをご依頼してみてください。

Prometheusとは - ユースケース

Prometheusは、最近、監視ソフトウェアとしての素晴らしい評判を得ています。その使いやすさ、汎用性、文字通り無限の統合オプションにより、監視および警告コミュニティで人気があります。これは、IoT、クラウドモニタリング、および文字通り考えられるその他のモニタリングのユースケースによく適合します。ただし、Prometheusが成功しない状況の1つは、プッシュベースのメトリックコレクションのユースケースです。 Prometheusを使用したPythonWebアプリの監視の記事でわかるように、いくつかの回避策があります。

プッシュされたメトリックを処理するためのPushgatewayがありますが、PushgatewayはPrometheusをプッシュベースの監視システムに変換することはできません。その唯一の目的は、上記で説明したように、短期間のジョブのある種のメトリックキャッシュとして機能することです。これとは別に、Prometheusはあなたが投げたもののほとんどすべてを処理し、それをしながら繁栄すると思います。

MetricFireによってマネージされているPrometheusとは

Prometheusは非常に強力なアプリケーションですが、起動して実行するにはかなりの量のインストールと構成が必要です。また、Prometheusは本質的にオープンソースであるため、メンテナンスと更新を手動で処理する必要があります。これを処理するには、専任のエンジニアチームが必要であり、コストと時間がかかります。

MetricFireが提供するような、ホストされたバージョンのPrometheusに切り替えると、余分な運用コストはすべて完全になくなります。メンテナンスの心配がなく、Prometheusをすぐに使用してスケーリングとデータの長期保管ができます。また、MetricFireチームが舞台裏ですべての更新を処理しているので、ログインするたびに常に最新バージョンのPrometheusを入手できます。HostedPrometheusオファリングを今すぐトライするために、デモの方をご予約ください。