【PrometheusとGraphite】どちらの監視ツールを使うべきかは、ユースケース次第

GraphiteとPrometheusは現在、モニタリングの世界では真っ向から対立しているように見えます。MetricFireでは、GraphiteとPrometheusの両方をサービスとして提供しており、MetricFireの見解として、この二つのどちらどちらも確かなオプションではありますが、ユーザーが決断を下す際に留意すべき重要なことは、結局どのように監視をしていきたいかということでしょう。

この記事では、最も重要な違いを紹介し、それぞれのサービスを使用した際にどのように比較されるかを見てみましょう。

そして、MetricFireのHosted GraphiteとHosted Prometheusの無料トライアルで是非、どのようにあなたの使用にフィットするかをお試しください。

概要

PrometheusとGraphiteは、どちらも時系列データベースを中心に構築されたオープンソースの監視プラットフォームです。すべてのデータポイントには、固有の時系列の一部として識別する名前および/またはタグが付けられています。Prometheusは常にタグ付け（Prometheus用語ではラベルと呼ばれています）をサポートしており、Graphiteは2018年にタグを導入しました。

PrometheusとGraphiteの間で最初に使い始めたときの最も明白な違いは、Prometheusがターゲットエンドポイントからメトリクスを要求するために手を差し伸べるところ（プル型）。反対にGraphiteは、フォーマットが正しいことを条件に、メトリクスが送られてきたものを受動的に受け取るということです（プッシュ型）。これは「Pull metrics vs Push metrics」と呼ばれ、サービス間の他の多くの違いの核となるモデルです。

Graphiteの仕組み

https://www.promlts.com/resources/prometheus-or-graphite#

Graphiteは10年前から存在し、大きな人気があります。しかし、サーバーを立ち上げて稼働させるのは少し厄介なこともあります。

GraphiteはPrometheusよりもはるかにシンプルなアーキテクチャを採用しており、3つのパーツに分かれています。

データの収集

Graphiteは3つのcarbonデーモンを持っていて、データポイントを新しいメトリクスに変換して集約したり、複数のストレージバックエンドにデータを渡すためのリレーを提供したりするオプションで、メトリクスのデータポイントの受信を処理します。Carbonは、様々なプロトコルのメトリクスを受動的に受信し、シンプルな文字列形式以外の要件はありません。これにより、アプリケーション内で簡単にメトリクスを生成し、UDPですぐに素早く送信したり、TCPでより確実に送信したり、ライン分離されたデータポイントやpythonのpickleオブジェクトでバッチ処理してバンドルしたりすることができます。

データポイントの保管

普通のGraphiteはWhisperデータベース形式でメトリクスを保存します。Carbonリレーはレプリケーションや一貫性のあるハッシュ処理を行い、冗長性とキャパシティを高めるためにシャード化されたメトリックストレージに対応します。Whisperでは、時間の経過とともに解決策をロールアップするためのルールを含めて、ストレージの総時間枠を前もって決定する必要があります。ストレージの基準が決定されると、ファイルが作成されるため、使用されるスペースの合計量はすぐに使用され、変更されることはありません。

データの可視化

Graphiteはシンプルなdjangoアプリを使ってメトリクスのグラフを可視化することが出来ます。Graphiteの関数を使ってクエリや変換を行ったり、Grafanaのような外部サービスへのアクセスを与えるためのレンダーAPIを提供することもできます。

Promethuesの仕組み

https://www.promlts.com/resources/prometheus-or-graphite#

PrometheusはGoogleのBorgmonツールの直系の子孫であり、高度にコンテナ化された環境を扱うエンジニアによって開発されました。これはSREs for SREsの使命の元、SREsのために作られたもので、いくつかの素晴らしい機能を持っていますが、それを最大限に活用するためにはより高度な専門的な知識とアクセスが必要です。既存のサービスとの統合は直感的ではないかもしれませんが、インストールして実行するだけであれば簡単です。

Prometheusは単純にパーツに分かれているわけではありませんが、仕事を完了させるために引き受けるタスクは同じように区別されていることに変わりはありません。

データポイントの取得

Prometheusは、HTTP 経由でメトリクスを要求するためにターゲット・エンドポイントに接続します。このジョブは、エンドポイントを含む静的な設定を含むか、またはサービス・ディスカバリを設定して、プロメティックをどこで探すかを Prom に伝えることができます。

データポイント格納

Prometheusは、メトリクスをローカルディスク上の1つに保存します。必要に応じて、settingで設定した「記録ルール」を使用して、メトリクスが保存される前にいくつかの変換を行うことができます。メトリクスは、最初は2時間ブロックに変換され、後でより長い期間のブロックに圧縮されるまでメモリに保存されます。デフォルトの保持は15日間です。Prometheusは、これがデータの長期保存のためではなく、データのスライドウィンドウとして使用することを想定しています。

データの可視化

Prometheusは、ユーザーがPrometheusクエリ言語（PromQL）を使用してメトリクスを探索したり、簡単なグラフを描画したりできるグラフィカルなインターフェイスを提供しています。また、監視対象のエンドポイントのビュー、任意のアラートルールとその現在のステータスのビュー、現在の構成を簡単に確認する方法も提供します。クエリAPIは、GrafanaのようなサードパーティアプリケーションがPromQLを使用してメトリックデータを要求することもできます。

アラート

PrometheusはGraphiteと違ってアラートを内蔵していますが、アラートのルールを確認したり、UIのページにアラートの状態を表示したりすることに限定的なところはあります。AlertManagerは別のツールで、複数のPrometheusサーバのアラート通知を一度に処理することができます。

それぞれのサービスを利用してみた感想は？

(1) 監視対象となるアプリケーションの書き方

監視の構築者が実際に監視するわけではないが、他のユーザーのために監視を出来るように設定しなければならないケース

Graphiteの長所:

1. Graphite形式のデータポイントを送信するためにアプリケーションコードに行を追加することは簡単で、比較的直感的でシンプルです。これを支援するモジュールやライブラリがいくつか存在しますが、それはあなた自身のものを書くのが最も簡単で、メンテナンスのための依存関係を持たないことになります。Hosted Graphite言語ガイドにいくつかの例がありますので、ご参考ください。

Graphiteの短所:

1. アプリケーションが非常にアクティブな場合、非常に短い時間枠で多くのデータポイントを送信することになり、Graphiteのインジェストプロセスを圧倒する可能性があります（これは、高頻度のバッチサービスで最も一般的な課題です）。
2. アウトバウンドトラフィックに制限がある場合、ファイアウォールの問題が発生する可能性があります。

Prometheusの長所:

1. Prometheus のメトリクスをコードに追加できる優れたクライアントライブラリがいくつかあり、/metrics エンドポイントの作成やリクエストに応じてデータを提供することに対応しています。エクスポータを書くためのガイドラインもあります。
2. 一度設定してしまえば、Prometheus のインスタンスが移動してもアプリの設定を変更する必要はありません。

Prometheusの短所:

1. クライアントライブラリは、追跡するための追加の依存関係を意味し、さらに、独自のモニタリングサーバーを管理していない場合は、メトリクスを取得するためのジョブを設定するために、Prometheus 管理者が常に必要になります。
2. Prometheus サーバは、アプリケーションが実行されているサーバやコンテナに接続するためのアクセス権を持っている必要があり、理想的には、サービスディスカバリを介して発見可能であるべきです。
3. アプリケーションが短命のサービスやバッチサービスの場合は、PrometheusのPushgatewayを設定する必要があるかもしれません。

(2) コンテナクラスタなどの単一環境の監視

自分で書いていないものも含めて、アプリケーションの動作環境やパフォーマンスを監視する責任のあるエンジニアやSREチーム向け

Graphiteの長所:

1. 多くの監視エージェントがありますが、彼らは与えられた任意のエンドポイントにGraphite形式のメトリクスを送信することができます。
2. 階層的なメトリックの命名形式は、環境の一般的な構造を論理的に反映した良い仕事をすることができます（環境→ノードグループ→サーバー→サービス）しかし、Graphiteはまた、必要に応じて多次元メトリックのためのタグ付けをサポートしています。
3. メトリクスはどこからでも中央のGraphiteサーバに送ることができ、冗長性のためにストレージクラスタを使用することができる。

Graphiteの短所:

1. ほとんどのモニタリングエージェントのデフォルトのドット階層メトリック名にはホスト名が含まれているため、ホスト名が変更されると（コンテナのスケーリングやAWS EC2インスタンスの再起動などで）、新しいメトリックセットが作成されます。
2. メトリクスの受信が停止した場合、その正確な意味は不明です - メトリクスの送信に問題があるのか、それともメトリクスの生成が停止したのか？は精査しないとわかりません。
3. 同様に、メトリクスの送信に問題がある新しいサーバ/サービスを立ち上げることもできますが、メトリクスが少なくとも一度は受信されるまでは、自動的に欠落していることを知る方法はありません。
4. アラート機能は、Grafana アラートや Cabot などのように、完全に別個に処理する必要があります。すべてのコンテナがメトリクスを外部に送信するアクセス権を持っているわけではない。
5. コンテナ用の監視エージェントで、Graphiteとの連携が良いものはあまりありません。クラスタやスウォームでの「ホスト名」の変更頻度は、無関係なデータでメトリックカウントを膨らませる可能性があります。

Prometheusの長所:

1. 環境に応じて、Dockerコンテナを監視するための主要なツールの1つであるcAdvisorを含め、Prometheusをサポートする監視エージェントは様々なものがあります。
2. スクラップするエンドポイントのリストを取得するには、サービスディスカバリーで対応できます - PrometheusはKubernetes用に構築されており、k8sのポッドやノードのコンテナは常に変化しているが、k8sは任意の瞬間にエンドポイントのリストを提供することができる。
3. スクラップジョブは、メトリクスが流れなくなった場合、エンドポイントが応答を停止したかどうかを簡単に発見できることを意味します - エンドポイントの状態は常に監視されています。
4. エンドポイントへのアクセスはローカルでPrometheusを実行することで処理されるため、外部のファイアウォールの問題が発生することはありません。

Prometheusの短所:

1. サービスディスカバリは限られた数のサービスでサポートされていますが、それ以降はDNSベースのディスカバリを使用するか、詳細が記載されたファイルを生成する必要があります。標準的なものを監視していない場合には、作成して維持するために特別なサービスが必要になります。
2. 限られた時間枠のメトリック・ストレージ、または環境上のリソースを使用するかのどちらかです。
3. すべてがクラスタ内で実行されているため、クラスタに問題が発生しても冗長性はありません。クラスタの外で実行すると追加コストが発生したり、コンテナ内のサービスへのアクセスに問題が発生したりする可能性がある
4. グローバルな組織をまたいで他のチームのサービスとして実行することは困難です。これについては、以下のセクション（複数の環境/ロケーションの監視）で説明します。

(3) 複数の環境・場所の監視

1つの環境だけでなく、物理的なロケーションやネットワークの異なる複数の環境を監視するSREまたは監視チーム向け

Graphite長所:

1. 各ロケーション/環境がアウトバウンドデータを送信する能力を付与することができれば、アクセスやパーミッションの問題はありません。
2. メトリクスは世界中の様々なロケーションで生成されるかもしれませんが、それらを見るためには一か所に行くように設定出来ます。
3. すべての環境は、モニタリングやメトリクスの生成のために好きなセットアップを使用することができ、各開発チームの専門家を準備する必要はありません。

Graphiteの短所:

1. Graphiteのエンドポイントが移動したり変更されたりした場合、新しい値をフリート全体にロールアウトし、適切なサービスを再起動してそれを拾う必要がある。
2. また、ネットワーク外のエンドポイントへのデータポイントの送信を妨害することができるセキュリティコンプライアンスのために、一般的にアウトバウンドトラフィックを制限する必要があるかもしれません。これらの問題は、ローカルのCarbonリレーやstatsdサーバを使用することで処理することができ、再設定が必要な場所の数を減らすことができますが、維持するための異なるサービスの数を増やすことになります。

Prometheusの長所:

1. 単一環境のセットアップのすべての利点。
2. Prometheusのインストールと設定を簡単に自動化できるので、この種のマルチサイトセットアップのメンテナンスが容易になります。

Prometheusの短所:

1. 多くの場合、環境を論理的に分離する必要があり、Prom は各サービスに HTTP 接続を行うためのアクセスが必要なので、通常はサービスと同じネットワーク内で実行する必要があります。
2. Prometheus フェデレーションを使用してメトリクスを一箇所に統合することは可能ですが、これは通常、ダウンサンプルやメトリクスの集約を意味します。各環境のサービスに直接アクセスできるため、SREにとっては問題にならないかもしれませんが、非SREにとっては、特に複数の環境/物理的な場所で動作するアプリケーションの場合、メトリクスを表示するためのアクセスを得るのは難しいかもしれません。

(4) グラフの見方、メトリクスの閲覧、アラートの設定など
ビジネスアナリスト、営業担当者、サポートエージェント、その他のユーザーは、自分が生成に関与していないデータからも、そのデータの意味を抽出したいと考えています。Prometheusは完全な監視をするためのシステムとして構築されているため、このような監視に詳しくない人物が理解するという意味では、最も理想的ではないソリューションかもしれません。

Graphite

• Graphiteは、モニタリングや（限定的な）異常検知だけでなく、ビジネスインテリジェンスやパフォーマンス分析など、あらゆる分野に適した機能を長年にわたって蓄積してきました。
• Graphiteのクエリ言語はシンプルなフォーマットで、プログラミングを少しでもやったことがある人なら誰でも知っているようなものです。それがなくても、それは非常に簡単に手に取ることができます。
• 階層的なメトリクスとオートコンプリートのサポートにより、メトリクスを生成するシステムについて直接知識がなくても、メトリクス名の参照が非常に簡単になります。Grafanaのようなツールは、メトリクスと同じように関数をブラウズできるようにするのに良い仕事をしています。
• Graphiteには個別のアラートサービスが必要ですが、カジュアルなユーザーにとってはGrafanaのアラートサービスで十分な場合が多いです。

Prometheus

• PromQLは特定の言語や既存の構造に基づいているわけではないので、一から学ぶ必要があります。複雑すぎるわけではありませんが、Graphiteの関数ほど単純ではありません。
• 階層構造がないので、メトリクスのブラウジングが貧弱で、Prom自体もあまり役に立ちません。関数とキーワードは同じことをしているように見えますが、使い方が異なります。メトリックを取得せずに利用可能なタグを参照する機能はなく、タグの利用可能な値を参照する機能もありません。
• どのようなメトリクスやラベルが存在し、それらが何を意味するのかをすでに知っているという強い推測がありますが、これは一部のユーザーにとっては合理的ですが、他のユーザーにとってはそうではありません。
• 必要なすべてのデータを取得するために、異なる Prometheus サーバーの束にログインしなければならないかもしれませんが、それがどこで実行されているか、統合されているかどうか、どのようなメトリクスが統合されているかによって異なります。
• 古いメトリクスが必要になるかもしれない - remote_write と remote_read がそれを助けてくれますし、Metricfire のようなサービスにストレージをアウトソースすることもできます。

あなたに最適なツールは何でしょうか？

要約すると、PrometheusとGraphiteのどちらを選択するかは、あなたの正確なシナリオに依存しています。この記事では、4つの主要なユースケースを想定して、両ツールの機能、類似点と相違点、長所と短所を見てきました。

これまで見てきたように、それぞれのツールにはそれぞれの長所と短所があり、正しい選択は特定のユースケースとセットアップによって異なります。

無駄なセットアップに時間をかけたくなく、すぐに監視を安価に始めたい方はサービス化されたMetricFireのHosted PrometheusとHosted Graphiteの両方を14日間の無料トライアルでお試しください。

また、こちらからデモをご予約いただけますので、さらに詳しい情報について、お尋ねください。

それでは、また次の記事で！