代替案との比較

Prometheus vs. Graphite

スコープ

Graphite は、クエリ言語とグラフ機能を備えたパッシブな時系列データベースであることに注力しています。その他の懸念事項は外部コンポーネントによって処理されます。

Prometheus は、時系列データに基づいたスクレイピング、保存、クエリ、グラフ作成、アラートを組み込んだ、完全な監視およびトレンドシステムです。監視対象の世界がどのようになるべきか（どのエンドポイントが存在すべきか、どの時系列パターンが問題を示すかなど）を把握しており、積極的に障害を見つけようとします。

データモデル

Graphite は、Prometheus と同様に、名前付き時系列の数値サンプルを格納します。しかし、Prometheus のメタデータモデルはより豊かです。Graphite のメトリック名はドットで区切られたコンポーネントで構成され、暗黙的にディメンションをエンコードしますが、Prometheus はディメンションをメトリック名に添付されたラベルと呼ばれるキーと値のペアとして明示的にエンコードします。これにより、クエリ言語を介したこれらのラベルによるフィルタリング、グループ化、マッチングが容易になります。

さらに、特に Graphite が StatsD と組み合わせて使用される場合、インスタンスをディメンションとして保持し、個々の問題のあるインスタンスをドリルダウンできるのではなく、すべての監視対象インスタンス全体の集計データのみを格納することが一般的です。

たとえば、API サーバーへの HTTP リクエスト数で、応答コードが 500、メソッドが POST、エンドポイントが /tracks である場合、Graphite/StatsD では一般的に次のようにエンコードされます。

stats.api-server.tracks.post.500 -> 93

Prometheus では、同じデータを次のようにエンコードできます（3 つの api-server インスタンスを想定）。

api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample1>"} -> 34
api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample2>"} -> 28
api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample3>"} -> 31

ストレージ

Graphite は、Whisper フォーマットでローカルディスクに時系列データを格納します。これは RRD スタイルのデータベースで、サンプルが定期的な間隔で到着することを想定しています。各時系列は個別のファイルに格納され、新しいサンプルは一定期間後に古いサンプルを上書きします。

Prometheus も時系列ごとに 1 つのローカルファイルを作成しますが、スクレイプやルール評価が発生したときに任意の間隔でサンプルを格納できます。新しいサンプルは単純に追加されるため、古いデータは任意に長く保持できます。Prometheus は、短命で頻繁に変更される多数の時系列セットにも適しています。

概要

Prometheus は、より豊富なデータモデルとクエリ言語を提供し、実行や環境への統合も容易です。履歴データを長期にわたって保持できるクラスタリングソリューションが必要な場合は、Graphite の方が適しているかもしれません。

Prometheus vs. InfluxDB

InfluxDB は、スケーリングとクラスタリングのための商用オプションを備えたオープンソースの時系列データベースです。InfluxDB プロジェクトは Prometheus の開発開始から約 1 年後にリリースされたため、当時は代替案として考慮できませんでした。それでも、Prometheus と InfluxDB の間には顕著な違いがあり、両方のシステムはわずかに異なるユースケースに対応しています。

スコープ

公平な比較のために、Kapacitor も InfluxDB と合わせて考慮する必要があります。なぜなら、これらを組み合わせることで、Prometheus と Alertmanager と同じ問題空間に対応できるからです。

InfluxDB 自体については、Graphite の場合と同様のスコープの違いが適用されます。さらに、InfluxDB は継続クエリを提供しており、これは Prometheus の記録ルールに相当します。

Kapacitor のスコープは、Prometheus の記録ルール、アラートルール、および Alertmanager の通知機能の組み合わせです。Prometheus は、グラフ作成とアラートのためのより強力なクエリ言語を提供します。Prometheus Alertmanager は、さらにグループ化、重複排除、サイレンス機能を提供します。

データモデル / ストレージ

Prometheus と同様に、InfluxDB のデータモデルにはキー・バリュー・ペアがラベルとして存在し、これはタグと呼ばれます。さらに、InfluxDB にはフィールドと呼ばれる 2 番目のレベルのラベルがあり、これは使用がより制限されています。InfluxDB は、最大ナノ秒解像度のタイムスタンプと、float64、int64、bool、文字列のデータ型をサポートします。対照的に、Prometheus は float64 データ型と限定的な文字列サポート、ミリ秒解像度のタイムスタンプをサポートします。

InfluxDB は、書き込み先頭ログを備えたログ構造化マージツリーをストレージに採用のバリアントを使用しており、時間によってシャーディングされています。これは、時系列ごとの追加専用ファイルという Prometheus のアプローチよりも、イベントロギングに適しています。

ログ、メトリック、グラフ - それは、なんだ！は、イベントロギングとメトリック記録の違いを説明しています。

アーキテクチャ

Prometheus サーバーは互いに独立して実行され、スクレイピング、ルール処理、アラートなどのコア機能のためにローカルストレージのみに依存します。InfluxDB のオープンソース版も同様です。

商用版の InfluxDB は、設計上、ストレージとクエリを複数のノードで同時に処理する分散ストレージクラスタです。

これは、商用版 InfluxDB が水平スケーリングを容易にできることを意味しますが、同時に、最初から分散ストレージシステムの複雑さを管理する必要があることも意味します。Prometheus は実行が簡単ですが、ある時点で製品、サービス、データセンター、または同様の側面のようなスケーラビリティの境界に沿ってサーバーを明示的にシャーディングする必要があります。独立したサーバー（並列で冗長に実行可能）は、より高い信頼性と障害分離を提供することもできます。

Kapacitor のオープンソース版には、ルール、アラート、通知のための組み込み分散/冗長オプションはありません。Kapacitor のオープンソース版は、Prometheus 自体と同様に、ユーザーによる手動シャーディングによってスケーリングできます。Influx は、Enterprise Kapacitor を提供しており、これは HA/冗長アラートシステムをサポートしています。

対照的に、Prometheus と Alertmanager は、Prometheus の冗長レプリカを実行し、Alertmanager の高可用性モードを使用することで、完全にオープンソースの冗長オプションを提供します。

概要

これらのシステムの間には多くの類似点があります。どちらも多次元メトリックを効率的にサポートするためのラベル（InfluxDB ではタグと呼ばれる）を持っています。どちらも基本的に同じデータ圧縮アルゴリズムを使用しています。どちらも、互いに連携を含む広範な統合を持っています。どちらも、統計ツールでのデータ分析や自動アクションの実行などの拡張を可能にするフックを備えています。

InfluxDB が優れている点

イベントロギングを行っている場合。
商用オプションは InfluxDB のクラスタリングを提供しており、長期データストレージにも適しています。
レプリカ間のデータの一貫したビュー（最終的な一貫性）。

Prometheus が優れている点

主にメトリックを扱っている場合。
より強力なクエリ言語、アラート、通知機能。
グラフ作成とアラートの可用性と稼働時間の向上。

InfluxDB は、クローズドソースのクラスタリング、ホスティング、サポートなどのプレミアム機能を提供する、オープンコアモデルに従う単一の商用企業によって維持されています。Prometheus は、完全にオープンソースで独立したプロジェクトであり、多くの企業や個人によって維持されており、それらの一部は商用サービスやサポートも提供しています。

Prometheus vs. OpenTSDB

OpenTSDB は、Hadoop および HBase をベースにした分散時系列データベースです。

スコープ

Graphite の場合と同様のスコープの違いがここにも適用されます。

データモデル

OpenTSDB のデータモデルは Prometheus のものとほぼ同じです。時系列は、一連の任意のキー・バリュー・ペア（OpenTSDB のタグは Prometheus のラベル）によって識別されます。メトリックのすべてのデータは一緒に格納され、メトリックのカーディナリティが制限されます。ただし、マイナーな違いもあります。Prometheus はラベル値に任意の文字を許可しますが、OpenTSDB はより制限的です。OpenTSDB はまた、API を介した単純な集計と数学のみを許可する、完全なクエリ言語を欠いています。

ストレージ

OpenTSDB のストレージは、Hadoop および HBase の上に実装されています。これは、OpenTSDB が水平スケーリングを容易にできることを意味しますが、最初から Hadoop/HBase クラスタを実行する全体的な複雑さを受け入れる必要があります。

Prometheus は当初実行が簡単ですが、単一ノードの容量を超えると明示的なシャーディングが必要になります。

概要

Prometheus は、より豊富なクエリ言語を提供し、より高いカーディナリティのメトリックを処理でき、完全な監視システムの一部を形成します。Hadoop を既に実行しており、これらの利点よりも長期ストレージを重視する場合は、OpenTSDB が良い選択肢です。

Prometheus vs. Nagios

Nagios は、1990 年代に NetSaint として始まった監視システムです。

スコープ

Nagios は主にスクリプトの終了コードに基づくアラートに関するものです。これらは「チェック」と呼ばれます。個々のアラートのサイレンス機能はありますが、グループ化、ルーティング、重複排除機能はありません。

さまざまなプラグインがあります。たとえば、perfData プラグインが返せる数キロバイトのデータを Graphite のような時系列データベースにパイプしたり、NRPE を使用してリモートマシンでチェックを実行したりします。

データモデル

Nagios はホストベースです。各ホストは 1 つ以上のサービスを持つことができ、各サービスは 1 つのチェックを実行できます。

ラベルやクエリ言語の概念はありません。

ストレージ

Nagios は、現在のチェック状態を超えるストレージを特に持っていません。視覚化のためのプラグインがあります（例：視覚化用）。

アーキテクチャ

Nagios サーバーはスタンドアロンです。チェックのすべての設定はファイル経由で行われます。

概要

Nagios は、ブラックボックスプロービングで十分な、中小規模または静的なシステムの基本的な監視に適しています。

ホワイトボックス監視を行いたい場合、または動的またはクラウドベースの環境がある場合は、Prometheus が良い選択肢です。

Prometheus vs. Sensu

Sensu は、スケーラビリティのための追加機能を提供する商用ディストリビューションを備えたオープンソースの監視・オブザーバビリティパイプラインです。既存の Nagios プラグインを再利用できます。

スコープ

Sensuは、オブザーバビリティデータをイベントのストリームとして処理およびアラートに焦点を当てたオブザーバビリティパイプラインです。イベントのフィルタリング、集約、変換、および処理のための拡張可能なフレームワークを提供します。これには、他のシステムへのアラート送信や、サードパーティシステムへのイベント保存が含まれます。Sensuのイベント処理機能は、PrometheusのアラートルールやAlertmanagerと同等の範囲です。

データモデル

Sensuのイベントは、サーバー、クラウドコンピューティングインスタンス、コンテナ、またはサービスなどのエンティティ名で識別されるサービスの状態やメトリックを構造化されたデータ形式で表現します。イベント名と、オプションで「ラベル」または「アノテーション」と呼ばれるキー/バリューメタデータによって識別されます。Sensuイベントペイロードには、1つ以上のメトリックポイントが含まれることがあり、これはname、tags（キー/バリューペア）、timestamp、およびvalue（常にfloat）を含むJSONオブジェクトとして表されます。

ストレージ

Sensuは、現在のイベントステータス情報とリアルタイムのインベントリデータを、組み込みデータベース（etcd）または外部RDBMS（PostgreSQL）に保存します。

アーキテクチャ

Sensuデプロイメントのすべてのコンポーネントは、高可用性とイベント処理スループットの向上を目的としてクラスタリングできます。

概要

SensuとPrometheusはいくつかの共通した機能を持っていますが、モニタリングへのアプローチは大きく異なります。どちらも、動的なクラウドベースの環境や一時的なコンピューティングプラットフォーム向けの拡張可能な検出メカニズムを提供しますが、基盤となるメカニズムはかなり異なります。どちらもラベルとアノテーションを介した多次元メトリックの収集をサポートしています。どちらも広範な統合機能を持っており、SensuはすべてのPrometheusエクスポーターからメトリックを収集することをネイティブにサポートしています。どちらもオブザーバビリティデータをサードパーティのデータプラットフォーム（イベントストアやTSDBなど）に転送できます。SensuとPrometheusの最も大きな違いは、ユースケースにあります。

Sensuが適している場合

ハイブリッドオブザーバビリティデータ（メトリックおよび/またはイベントを含む）を収集・処理する場合
複数のモニタリングツールを統合し、メトリックとNagiosスタイルのプラグインまたはチェックスクリプトのサポートが必要な場合
より強力なイベント処理プラットフォーム

Prometheus が優れている点

主にメトリックを収集・評価する場合
均質なKubernetesインフラストラクチャを監視する場合（監視対象のワークロードが100％K8sにある場合、Prometheusはより優れたK8s統合を提供します）
より強力なクエリ言語と、履歴データ分析の組み込みサポート

Sensuは、クローズドソースのイベント相関および集約、フェデレーション、サポートなどのプレミアム機能を提供するオープンコアビジネスモデルを採用する単一の商用企業によって保守されています。Prometheusは、複数の企業や個人によって保守されている完全にオープンソースで独立したプロジェクトであり、その中には商用サービスやサポートを提供する企業や個人もいます。

このページの内容