代替案との比較

Prometheus vs. Graphite

スコープ

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

Prometheus は、時系列データに基づく組み込みのアクティブなスクレイピング、保存、クエリ、グラフ作成、およびアラートを含む、完全な監視およびトレンドシステムです。 Prometheus は、世界がどのように見えるべきか(どのエンドポイントが存在すべきか、どの時系列パターンが問題があるかなど)に関する知識を持ち、積極的に障害を見つけようとします。

データモデル

Graphite は、Prometheus と同様に、名前付きの時系列の数値サンプルを保存します。ただし、Prometheus のメタデータモデルはより豊富です。Graphite のメトリクス名はドットで区切られたコンポーネントで構成されており、暗黙的にディメンションをエンコードしていますが、Prometheus はディメンションを、メトリクス名に付加されたラベルと呼ばれるキーと値のペアとして明示的にエンコードします。これにより、クエリ言語を介してこれらのラベルで簡単にフィルタリング、グループ化、および照合できます。

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

たとえば、レスポンスコード 500 とメソッド POST を使用して /tracks エンドポイントに対する HTTP リクエストの数を保存することは、通常、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 には大きな違いがあり、両方のシステムはわずかに異なるユースケースを対象としています。

スコープ

公平な比較のために、Prometheus と Alertmanager と同じ問題空間に対処するため、Kapacitor も InfluxDB と合わせて考慮する必要があります。

Graphite の場合と同じスコープの違いが、InfluxDB 自体にも適用されます。さらに、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 は、HA/冗長アラートシステムをサポートする Enterprise Kapacitor を提供しています。

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

概要

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

InfluxDB の方が優れている場合

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

Prometheus の方が優れている場合

  • 主にメトリクスを実行している場合。
  • より強力なクエリ言語、アラート、および通知機能。
  • グラフ作成とアラートの可用性と稼働率が高い。

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

Prometheus vs. OpenTSDB

OpenTSDB は、HadoopHBase に基づく分散時系列データベースです。

スコープ

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

データモデル

OpenTSDBのデータモデルはPrometheusのものとほぼ同じです。時系列データは、任意のキーと値のペア(OpenTSDBのタグはPrometheusのラベル)で識別されます。メトリクスのすべてのデータはまとめて保存されるため、メトリクスのカーディナリティが制限されます。ただし、細かい違いもあります。Prometheusはラベルの値に任意の文字を使用できますが、OpenTSDBはより制限的です。また、OpenTSDBには完全なクエリ言語はなく、APIを介した単純な集計と算術演算のみが可能です。

ストレージ

OpenTSDBのストレージは、HadoopHBaseの上に実装されています。これは、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つ以上のメトリクスpointsが含まれる場合があります。これらは、nametags(キー/値のペア)、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は、完全にオープンソースで独立したプロジェクトであり、多くの企業や個人によってメンテナンスされており、その一部は商用サービスとサポートも提供しています。

このドキュメントはオープンソースです。問題の報告やプルリクエストを送信して、改善にご協力ください。