データベース

Prometheus VS InfluxDB



Prometheus Vs Influxdb



序文

Nagios、Zabbix、Sensuなどの従来の監視システムに加えて、時系列データベースベースの監視システムは、InfluxDBなどのPrometheusなどのマイクロサービスの台頭とともに人気が高まっています。 Gttはまた、将来の選択に役立つ情報を提供するために、2つのシステムの違いを見つけることを期待して、これら2つのシステムを試しました。

まず第一に、時系列データベースは古いrrdtoolsと 黒鉛 これらの古典的な古いシステムは非常にうまく機能しますが、大規模なシナリオで拡張できないことを嫌う人もいれば、失望させるのは不便です。そのため、OpenTSDB、Prometheus、InfluxDBなどの新進気鋭のスターがいます。



監視システム

OpenTSDB

OpenTSDB ：HadoopとHBaseの時系列データベースに基づいて、タグ（キーとキーとキーと値のペア）をメトリックに追加して、より便利で強力なクエリ構文を実現する方法を最初に提案しました。 InfluxDBの設計とクエリ構文はそれに触発されています。大きい。 OpenTSDBはHadoopとHBaseに基づいてメタモルフォーゼのスケールアウトを実現しますが、これら2つの依存関係のため、OpenTSDBは、Hadoopに精通していないチームの保守に費用がかかるため、誰かがInfluxDBを作成しました。

InfluxDB

InfluxDB ：InfluxDataは、golangによって実装された時系列データベースを使用します。 InfluxDBのスローガンの1つは、次のとおりです。From the ground up外部依存関係がなくても、実行可能ファイルをサーバー上で実行でき、操作と保守に非常に便利です。文法のデザインは、OpenTSDBに大きく影響を受けています。プロジェクトは当初、独自のクラスタリング機能を宣伝していましたが、水平統合を実現するのは非常に簡単です。ただし、InfluxDB 1.0以降では、クラスター機能が削除され、リレーモードを介して高可用性が実現されます。公式文書には以下の指示があります。 ただし、0.9バージョンのクラスター命令は公式ウェブサイトから引き続きアクセスでき、将来削除される可能性が非常に高いと推定されます。 。



注：クラスタリングは現在、InfluxEnterpriseと呼ばれる商用製品です。詳細については、こちらをご覧ください。

プロメテウス

プロメテウス ：SoundCloudのオープンソース監視システムは、独立した運用のためにオープンソースコミュニティに提出されました。そしてk8sのように Cloud Native Computing Foundation メンバーは、現在この財団にはk8sとPrometheusの2つのプロジェクトしかありませんが。 Prometheusと上記の最大の違いは、次のように理解できます。上記の2つは単なるデータベースであり、Prometheusは、時系列データベースだけでなく、取得、取得、描画、および警告の機能も含む監視システムです。 関係者はまた、この違いの詳細な説明をしました。 。

これは主に、プルモードに基づく監視システムであるGoogleの内部Borgmonシステムに触発されています。 「サイト信頼性工学」という本の中で、私はこの文章でプロメテウスについて言及しました。もちろん、BosunとRiemannの元の監視システムが言及されていることはお伝えしません。これが、この文の最後に省略記号がある理由です。



BorgmonはGoogleの内部にとどまっていますが、時系列データをアラートを生成するためのデータソースとして扱うというアイデアは、Prometheusなどのオープンソースツールを介して誰でもアクセスできるようになりました[…]»
—サイト信頼性エンジニアリング：Googleが本番システムを実行する方法（O’Reilly Media）

ただし、InfluxDataは、時系列データベースに関する完全なソリューションも導入しました。TICKは、データ収集（Telegraf）、ストレージとクエリ（InfluxDB）、チャート描画（Chronograf）、およびアラーム（Kapacitor）をカバーします。このソリューションとElasticのアプローチは特に似ています。ElasticSearchのコア機能、Logstash、Kibanaの買収、Beat、Watcher、その他の周辺サービスの登場により、完全でフル機能のフルテキスト検索ソリューションが作成されます。

少し遠いですが、記事の核心に戻ります。InfluxDBとPrometheusの違いは欠陥です。現在の主な違いは、前者は単なるデータベースであり、クライアントデータの挿入とクエリの要求を受動的に受け入れることです。後者は、データのキャプチャ、データのクエリ、アラーム、その他の機能を実行できる完全な監視システムです。

プッシュvsプル

この時点で、Prometheusはプルに基づいており、InfluxDBはプッシュに基づいていることがわかります。プッシュアンドプルの前に書かれています ansibleとpuppetの比較 しかし、監視システムには微妙な違いがあります。

まず、プッシュとプルはデータの送信方法を説明し、送信の内容には影響しません。言い換えれば、プッシュが伝送できる情報である限り、プルは、プルかプッシュか、送信の内容、またはこれらの監視データなど、「CPU使用率30％」などの同じ情報を確実に伝送できます。 、送信モードにより変化しません。その結果、メッセージの量が非常に長いため、2つの方法で消費されるネットワーク帯域幅は大きく変化しません。

Gttは、プッシュとプルの主な違いは次のとおりだと考えています。

さまざまなイニシエーター

プルのイニシエーターは監視システムであり、監視対象のターゲットを順番にポーリングするため、ターゲットがファイアウォールの内側またはNATの背後にある場合、プルモードは機能しません。また、バッチタイプのタスクの場合、全体の処理時間がポーリング間隔よりも短い可能性があるため、監視システムはそのようなタスクのデータをキャプチャしない可能性があります。

これら2つの問題を解決するために、Prometheusはpushgateway_exporterコンポーネントを提供して、プッシュモードの監視ニーズをサポートします。

プッシュでは、イニシエーターを監視対象にする必要があるため、ファイアウォールの制限を突破できます。ターゲットがNATの背後にある場合でも、データをスムーズにプッシュでき、バッチタイプのタスクでも比較的穏やかにデータを送信できます。

さらに、「シングルモードの監視システムは単一点であり、プルモードではないのに単一障害点とパフォーマンスのボトルネックが発生する」と言う人もいます。

ここでggtは同意しません。単一障害点を解決する方法は、別の監視システムを追加することです。これは、本質的にデータの冗長性を通じて信頼性を向上させることです。それでは、なぜ2つの監視システムにプッシュできないのでしょうか。データの冗長性。

パフォーマンスのボトルネックについては、これはさらに不十分です。プッシュかプルかにかかわらず、唯一の影響は送信モードであり、送信データコンテンツには影響せず、占有帯域幅は同じです。唯一の違いは、並行性が異なる可能性があることです。プッシュモードでは、ターゲットサービスが特定の時間にデータを監視システムにプッシュし、DDos攻撃と同様に大きな同時リクエストが発生する可能性があります。逆に、ターゲットサービスをポーリングするために、pullは、耐えられる同時実行の程度に従って監視データを処理し、監視データが短時間で噴出する状況を回避できます。ただし、解決策もあります。プッシュモードでは、監視サービスに要求処理キューが追加されます。監視システムの負荷を超える要求は一時的にキューに保存されるため、監視システムは独自のリズムに従ってデータを処理し、チームメートがDDosを提供するのを防ぐことができます。

したがって、シングルポイントの問題とパフォーマンスの問題は、2つのモードの本質的な違いではありません。

異なる論理アーキテクチャ

プッシュでは、監視対象のターゲットが監視システムのアドレス（IPまたはドメイン名）を知っている必要があるため、情報のこの部分をターゲットサービスに設定する必要があります。つまり、ターゲットサービスは監視システムに依存します。監視システムがアドレスを変更した場合は、それに応じてすべてのターゲットサービスを変更する必要があります。依存関係が生成されると、監視システムに障害が発生し、ターゲットサービスの通常の動作に影響を与える可能性があることを意味します。もちろん、プログラミング中にある程度の回避を行うことはできますが、それでも論理的にはターゲットサービスに依存する監視システムです。以下のアーキテクチャ図は次のとおりです。

画像

プルでは、​​監視システムがすべてのターゲットサービスのアドレスを知っている必要があり、ターゲットサービスは監視システムを認識していません。したがって、監視システムはターゲットサービスに依存し、新しいターゲットサービスが追加されるたびに、監視システムの構成が変更されます。この観点から、プルモードは論理アーキテクチャとより一致しています。ターゲットサービスの追加と削除の処理を自動化するために、PrometheusはService discovery systemターゲットサービスのアドレスを動的に取得することで、大規模なマイクロサービス展開の場合の複雑な構成要件を排除します。論理アーキテクチャを以下に示します。

（二）

ニワトリ泥棒は見つけなければなりませんね？Service discovery systemそれはすべての標的サービスに依存していますか？はい、サービス検出システムと監視システムは論理アーキテクチャ内で異なる位置にあります。Service discoveryアーキテクチャでは、ターゲットサービスが「検出」されていない場合、実際にはサービスを適切に提供できないため、サービスを適切に提供する必要があります。依存するService discovery system逆に、ターゲットサービスは、システムを監視しなくても正常に動作できます。論理アーキテクチャを以下に示します。

（3）

監視システムに依存しないため、監視サービスが展開されていなくても、ターゲットサービスが正常であるかどうかを手動で判断するのは非常に簡単です。アナログ監視システムがターゲットサービスのインターフェースにアクセスしている限り、プルモードでの監視はより白く、すべての情報を簡単に取得できます。逆に、プッシュモードは整形式の監視サービスに依存しています。ターゲットサービスが監視サービスなしで実行されていることを知ることは受け入れられません。

クエリ構文

この時点で、Prometheusはデータを取得するためのプルモードに基づいており、InfluxDBはデータを取得するためのプッシュモードに基づいていることがわかります。次に、データクエリの2つの違いに注目します。

たとえば、ディスクIO時間のデータを取得するには、次のようにします。

Timestamp metric: value tag 1475216224 disk_io_time:10 type='sda' 1475216224 disk_io_time: 30 type='sdb' 1475216224 disk_io_time: 11 type='sdc' 1475216224 disk_io_time: 18 type='sde'

基本的なクエリ

基本的な時系列データベースとして、データの基本的な取得はどちらも簡単です。

InfluxDB：

SELECT mean('value') FROM 'disk_io_time' WHERE $timeFilter GROUP BY time($interval), 'instance' fill(null)

プロメテウス：

disk_io_time

基本的な算術計算

2つの違いは大きくありません：

InfluxDB：

SELECT mean('value') *1024 FROM 'disk_io_time' WHERE $timeFilter GROUP BY time($interval), 'instance' fill(null)

プロメテウス：

disk_io_time*1024

計算速度

InfluxDB：

SELECT derivative(mean('value'), 10s) *1024 FROM 'disk_io_time' WHERE $timeFilter GROUP BY time($interval), 'instance' fill(null)

プロメテウス：

rate(disk_io_time)*1024

寸法間の計算

これは、これまでにgttによって検出された2つの間の最大の違いです。たとえば、io時間を追加するにはsdaとsdcが必要です。 InfluxDBはそのような構文をサポートしていませんが、コミュニティはすでに関連する実装について議論しています。 [機能リクエスト]測定全体の数学＃3552 。

Prometheusはこのタスクを実行できます。

rate(disk_io_time{type='sda'}) + rate(disk_io_time{type='sdc'})

総括する

全体として、Prometheusは信頼性の高い監視システムであり、その設計はGoogleの内部Borgmonシステムに深く影響を受けており、洗練されたクエリ構文を備えていますが、プルモードに基づいて、特定のビジネスで選択する必要があります。 。 InfluxDBは、他の監視関連機能を備えていない単なる時系列データベースですが、InfluxDataは、選択可能な他のさまざまなコンポーネントを提供します。 Prometheusと比較すると、そのクエリ構文はより複雑であり、ディメンション間の計算をサポートしていません。

この記事はナゲッツからのものです- Prometheus VS InfluxDB