代替システムとの比較

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では、同じデータがこのようにエンコードされます（APIサーバーのインスタンスが3つあると仮定した場合）

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と同じ問題領域を扱えるからです。

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

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

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

Prometheusと同様に、InfluxDBのデータモデルもキーと値のペアをラベルとして持ち、これはタグと呼ばれます。さらに、InfluxDBにはフィールドと呼ばれる2番目のレベルのラベルがあり、その使用はより限定的です。InfluxDBはナノ秒単位までのタイムスタンプと、float64、int64、bool、およびstringのデータ型をサポートしています。対照的に、Prometheusはfloat64データ型をサポートし、文字列のサポートは限定的で、ミリ秒単位のタイムスタンプをサポートしています。

InfluxDBは、時間を基準にシャーディングされたライトアヘッドログを備えたログ構造マージツリーのバリアントを使用しています。これは、Prometheusの時系列ごとの追記のみのファイルアプローチよりもイベントログ記録に適しています。

ログとメトリックとグラフ、オーマイ！では、イベントログとメトリック記録の違いについて説明しています。

アーキテクチャ

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

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

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

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

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 と Sensu の比較

Sensuは、スケーラビリティのための追加機能を提供する商用版も利用可能なオープンソースの監視および可観測性パイプラインです。既存のNagiosプラグインを再利用できます。

範囲

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

データモデル

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

ストレージ

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

アーキテクチャ

Sensuデプロイメントのすべてのコンポーネントは、高可用性とイベント処理スループット向上のためにクラスタ化できます。

概要

SensuとPrometheusにはいくつかの共通機能がありますが、監視に対するアプローチは大きく異なります。両者とも、動的なクラウドベース環境と一時的な計算プラットフォームに対する拡張可能なディスカバリーメカニズムを提供しますが、根本的なメカニズムはかなり異なります。両者とも、ラベルとアノテーションを介した多次元メトリクス収集をサポートしています。両者とも広範な統合機能を持ち、SensuはすべてのPrometheusエクスポーターからのメトリクス収集をネイティブにサポートしています。両者とも、可観測性データをサードパーティのデータプラットフォーム（例：イベントストアやTSDB）に転送することができます。SensuとPrometheusの最大の違いは、ユースケースにあります。

Sensuが優れている点

• ハイブリッドな可観測性データ（メトリクス**および/または**イベントを含む）を収集および処理する場合
• 複数の監視ツールを統合し、メトリクス**と**Nagiosスタイルのプラグインまたはチェックスクリプトのサポートが必要な場合
• より強力なイベント処理プラットフォーム

Prometheusが優れている点

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

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