Prometheus のデータ ストレージの選択: Thanos と VictoriaMetrics

こんにちは、みんな。 以下は転写です Big Monitoring Meetup 4 からのレポート.

プロメテウス – さまざまなシステムおよびサービスの監視システム。これを使用すると、システム管理者はシステムの現在のパラメータに関する情報を収集し、システムの動作の逸脱に関する通知を受け取るためのアラートを設定できます。

レポートには比較が含まれます Thanosさん и ビクトリアメトリクス — Prometheus メトリクスを長期保存するためのプロジェクト。

まずはプロメテウスについてお話します。 これは、指定されたターゲットからメトリクスを収集し、ローカル ストレージに保存する監視システムです。 Prometheus は、メトリクスをリモート ストレージに記録し、アラートと記録ルールを生成できます。

プロメテウスの制限:

• グローバル クエリ ビューはありません。 これは、prometheus の独立したインスタンスが複数ある場合です。 彼らはメトリクスを収集します。 そして、さまざまなプロメテウス インスタンスから収集されたこれらすべてのメトリクスに基づいてクエリを実行したいと考えています。 プロメテウスはこれを許しません。
• prometheus では、パフォーマンスは XNUMX つのサーバーのみに制限されます。 Prometheus は、複数のサーバー間で自動的にスケールしません。 ターゲットを複数の Prometheus 間で手動でのみ分割できます。
• Prometheus のメトリクスの範囲は、複数のサーバーにわたって自動的に拡張できないのと同じ理由で、XNUMX つのサーバーのみに制限されます。
• Prometheus でデータの安全性を整理するのはそれほど簡単ではありません。

これらの問題/課題の解決策はありますか?

解決策は次のとおりです。

• Thanosさん
• ビクトリアメトリクス
• ウーバー M3
• 皮質

これらのソリューションはすべて、Prometheus によって収集されたデータのリモート ストレージ用です。 前のスライドで示したリモート ストレージの問題をさまざまな方法で解決します。 このプレゼンテーションでは、最初の XNUMX つのソリューションについてのみ説明します。 Thanosさん и ビクトリアメトリクス.

初めての情報としては、 Thanosさん によって登場した このリンク。 アーキテクチャについてはそこで説明されています Thanosさん そしてそれがどのように機能するか。

Thanos は、Prometheus がローカル ディスクに保存したデータを取得し、S3 にコピーします。 GCS または別のオブジェクトストレージに移動します。

したがって、Thanos はグローバル クエリ ビューを提供します。 複数の Prometheus インスタンスからオブジェクト ストレージに保存されているデータをクエリできます。

Thanos は PromQL をサポートしており、 Prometheus クエリ API.

Thanos は Prometheus コードを使用してデータを保存します。

Thanos は Prometheus と同じ開発者によって開発されています。

オン ビクトリアメトリクス。 ここに リンク、最初に話した場所 ビクトリアメトリクス.

VictoriaMetrics は複数のプロメテウスからデータを受信します リモート書き込みAPI Prometheus がサポートするプロトコル。

VictoriaMetrics は、複数の Prometheus インスタンスが XNUMX つの VictoriaMetrics にデータを書き込むことができるため、グローバル クエリ ビューを提供します。 したがって、このすべてのデータに対してクエリを実行できます。

VictoriaMetrics は、Thanos と同様、PromQL、Prometheus クエリ API もサポートしています。

Thanos とは異なり、VictoriaMetrics のソース コードは最初から書かれており、速度とリソース消費を考慮して最適化されています。

VictoriaMetrics は、Thanos とは異なり、垂直方向と水平方向の両方にスケーリングします。 食べる 単一ノードバージョン、垂直方向に拡大縮小します。 1 つのプロセッサと 1 GB のメモリから始めて、徐々に数百のプロセッサと 100 TB のメモリまで拡張できます。 VictoriaMetrics はこれらすべてのリソースを使用できます。 1コアシステムに比べてパフォーマンスが約XNUMX倍向上します。

Thanos の歴史は、最初の公開コミットが登場した 2017 年 XNUMX 月に始まりました。 これ以前、Thanos は社内で開発されていました ありえない.io.

2019 年 0.5.0 月に画期的なリリース XNUMX がリリースされました。 削除されました ゴシップ プロトコル。 彼はパフォーマンスが良くなかったため、サノスから外されました。 多くの場合、Thanos クラスターは正しく動作せず、ゴシップ プロトコルが原因でノードが誤ってクラスターに接続されました。 したがって、私たちは彼をそこから排除することにしました。 これは正しい決断だと思います。

同じ2019年XNUMX月に、彼らは申請番号を送信しました 256 в クラウドネイティブコンピューティング基盤.

そして数か月後、サノスは クラウドネイティブコンピューティング基盤これには、Prometheus、Kubernetes、その他の人気のあるプロジェクトが含まれます。

2018 年 XNUMX 月に VictoriaMetrics の開発が始まりました。

2018 年 XNUMX 月に、私は VictoriaMetrics について初めて公の場で言及しました。

2018 年 XNUMX 月に、単一ノード バージョンが公開されました。

5月に2019 公開されました シングルノード バージョンとクラスター バージョンの両方のソース。

2019年XNUMX月、サノスと同様に、私たちはCNCF財団に次の番号で申請書を提出しました。 255。 サノスが申請するXNUMX日前に申請しました。

しかし、残念ながら、私たちはまだそこに受け入れられていません。 コミュニティの助けが必要です。

Thanos と VictoriaMetrics のアーキテクチャを示す最も重要なスライドを見てみましょう。

サノスから始めましょう。 黄色のコンポーネントは Prometheus コンポーネントです。 それ以外はすべてThanosのコンポーネントです。 最も重要なコンポーネントから始めましょう。 Thanos Sidecar は、すべての Prometheus の隣にインストールされるコンポーネントです。 Prometheus データをローカル ストレージから S3 または別のオブジェクト ストレージにロードします。

Thanos Store Gateway と呼ばれるコンポーネントもあり、Thanos Query からのリクエストを受信すると、オブジェクト ストレージからこのデータを読み取ることができます。 Thanos Query は PromQL と Prometheus API を実装しています。 つまり、外から見るとプロメテウスのように見えます。 PromQL クエリを受信して​​ Thanos Store Gateway に送信し、Thanos Store Gateway がオブジェクト ストレージから必要なデータを取得して送り返します。

ただし、Thanos Sidecar 実装の機能により、最後の 3 時間を除いて Object Storage にデータを保存します。これは、Prometheus がローカル ストレージにこの XNUMX 時間のファイルをまだ作成していないため、最後の XNUMX 時間を Object Storage SXNUMX にアップロードできません。

これをどうやって回避しようと決めたのですか？ Thanos Query は、Thanos Store Gateway へのリクエストに加えて、Prometheus の隣にある各 Thanos サイドカーに並行リクエストを送信します。

そして、Thanos Sidecar はさらにリクエストを Prometheus にプロキシし、過去 XNUMX 時間のデータを取得します。

これらのコンポーネントに加えて、Thanos が適切に動作しないオプションのコンポーネントもあります。 これは Thanos Compact で、オブジェクト ストレージ上の小さなファイルを、Thanos Sidecars によってここにアップロードされた大きなファイルにマージする役割を果たします。 Thanos Sidecar はそこに XNUMX 時間でデータ ファイルをアップロードします。 これらのファイルは、より大きなファイルにマージされない場合、その数が大幅に増加する可能性があります。 このようなファイルが増えると、Thanos Store Gateway に必要なメモリが増え、ネットワークやメタデータを介してデータを転送するために必要なリソースも増えます。 Thanos Store Gateway が無効になります。 したがって、小さなファイルを大きなファイルにマージする Thanos Compact を実行して、そのようなファイルの数を減らし、Thanos Store Gateway のオーバーヘッドを削減する必要があります。

Thanos Ruler などのコンポーネントもあります。 Prometheus アラート ルールを実行し、データを Object Storage に書き戻すために Prometheus 記録ルールを評価できます。 ただし、このコンポーネントの使用はお勧めできません。理由は次のとおりです。 彼 不完全なデータを返す傾向がある.

これがサノスの単純な計画です。

次に、VictoriaMetrics スキームと比較してみましょう。

VictoriaMetrics には、シングルノード バージョンとクラスター バージョンの 2 つのバージョンがあります。 シングルノードは XNUMX 台のコンピューター上で実行されます。 シングルノードにはこれらのコンポーネントはなく、バイナリが XNUMX つだけあります。 スライド上のこのバイナリは、この正方形のように見えます。 四角形の中にあるものはすべて、単一ノード バージョンのバイナリ ファイルの内容です。 彼のことを知る必要はありません。 バイナリを実行するだけですべてが機能します。

クラスター バージョンはさらに複雑です。 その中には、vmselect、vminsert、vmstorage という XNUMX つの異なるコンポーネントがあります。 名前から、それぞれが何をするかは明らかです。 Insert コンポーネントは、Prometheus リモート書き込み API、Influx ライン プロトコル、Graphite プロトコル、OpenTSDB プロトコルなど、さまざまな形式のデータを受け入れます。 Insert コンポーネントはそれらを受け入れ、解析し、データがすでに保存されている既存のストレージ コンポーネント間でそれらを配布します。 次に、Select コンポーネントは PromQL クエリを受け入れます。 彼は実装します PromQL、Prometheus クエリ API と同様に、Grafana または他の Prometheus API クライアントの Prometheus の代替として使用できます。 Select は promql リクエストを受け入れ、解析し、このリクエストの実行に必要なデータをストレージ ノードから読み取り、このデータを処理して応答を返します。

Thanos と VictoriaMetrics のインストールの複雑さを比較してみましょう。

サノスから始めましょう。 Thanos の使用を開始する前に、Thanos Sidecar がデータを書き込めるように、S3 や GCS などのオブジェクト ストレージにバケットを作成する必要があります。

次に、Prometheus ごとに Thanos Sidecar をインストールする必要があります。 その前に、Prometheus でデータ圧縮を忘れずに無効にする必要があります。 データ圧縮では、リソースの消費を削減するためにローカル Prometheus ストレージ内のデータを定期的に圧縮します。

Prometheus に Thanos Sidecar をインストールする場合は、データ コンパクションが有効になっていると Thanos Sidecar が正しく動作しないため、このデータ コンパクションを無効にする必要があります。 これは、Prometheus が XNUMX 時間のブロックでデータの保存を開始し、それらのブロックをより大きなブロックにマージすることを停止することを意味します。 したがって、過去 XNUMX 時間を超えるクエリを作成すると、データ圧縮が有効になっている場合ほど効率的に動作しなくなります。

したがって、Thanos は、多数の小さなブロックのオーバーヘッドを削減するために、ローカル ストレージでのデータ保持時間を 6 ～ 8 時間に短縮することを推奨しています。

Thanos Sidecar をインストールしたら、オブジェクト ストレージ バケットごとに XNUMX つのコンポーネントをインストールする必要があります。 それはThanos CompactorとThanos Store Gatewayです。

その後、Thanos Query をインストールし、所有しているすべての Thanos ストア ゲートウェイに接続できるように、またすべての Thanos サイドカーにも接続できるように設定する必要があります。

ここで少し問題があるかもしれません。

Thanos Query からこれらのコンポーネントへの信頼性が高く安全な接続を構成する必要があります。 また、Prometheus が別のデータセンターまたは別の VPC にある場合、外部からの接続は禁止されます。 ただし、Thanos Query が機能するには、何らかの方法で接続を設定する必要があり、その方法を見つける必要があります。

このようなデータセンターが多数存在すると、それに応じてシステム全体の信頼性が低下します。 Thanos Query は、異なるデータセンターにあるすべての Thanos サイドカーへの接続を常に維持する必要があるため。 リクエストが届くたびに、すべての Thanos サイドカーにリクエストをルーティングします。 接続が中断されると、不完全なデータセットを受信するか、「クラスターが停止しています」という応答を受信することになります。

VictoriaMetrics では、すべてが少しシンプルになります。 単一ノード バージョンの場合は、XNUMX つのバイナリを実行するだけですべてが機能します。

クラスター バージョンでは、上記の XNUMX 種類のコンポーネントをすべて必要なだけ実行するか、次のコマンドを使用するだけで十分です。 ヘルムチャート Kubernetes でのコンポーネントの起動を自動化します。 Kubernetesオペレーターも作る予定です。 Helm チャートではいくつかのケースがカバーされていないため、自分自身を攻撃する可能性があります。 たとえば、データ損失につながるストレージ ノードの数を減らすことができます。

XNUMX つのバイナリまたはクラスター化されたバージョンを起動したら、Prometheus を構成に追加するだけです。 リモート書き込み URL の設定これにより、ローカル ストレージとリモート ストレージへのデータの書き込みが並行して開始されます。 ご覧のとおり、この構成は Thanos 構成と比較してはるかに信頼性の高いパフォーマンスを発揮するはずです。 Prometheus 自体が VictoriaMetrics に接続してデータを送信するため、VictoriaMetrics からすべての Prometheus への接続を維持する必要はありません。

Thanos と VictoriaMetrics のサポートを考えてみましょう。

Thanos は、Sidecar がオブジェクト ストレージへのデータの読み込みを停止しないように監視する必要があります。 オブジェクト・ストレージへのネットワーク接続が一時的に中断されたり、オブジェクト・ストレージが一時的に利用できなくなったりするなど、ダウンロード・エラーが原因でこのデータのダウンロードが停止される場合があります。 Thanos Sidecar はこの時点でこれに気づき、エラーを報告し、クラッシュして動作を停止する可能性があります。 これを監視しないと、オブジェクトストレージへのデータ転送が停止します。 保持期間 (6 ～ 8 時間を推奨) が経過すると、オブジェクトストレージに保存されなかったデータが失われます。

サノスのコンパクターは次の理由で動作を停止する可能性があります サイドカーでレース。 コンパクターは、オブジェクト ストレージからデータを取得し、それをより大きなデータにマージします。 コンパクターはサイドカーと同期していないため、次のことが発生する可能性があります。サイドカーにはブロックを完了する時間がまだなく、コンパクターはこのブロックが完全に書き込まれたと判断します。 コンパクターはそれを読み取り始めます。 ブロックを完全に読み取ることができず、動作が停止します。 詳細を見る ここで.

ストア ゲートウェイは、Compactor と Sidecar 間の競合により、一貫性のないデータを返す場合があります。 ストア ゲートウェイはコンパクターやサイドカーとまったく同期していないため、ここでも同じことが発生します。 したがって、ストア ゲートウェイがデータの一部を認識しないか、または不要なデータを認識すると、競合状態が発生する可能性があります。

Thanos の Query コンポーネントは、一部のサイドカーまたはストア ゲートウェイが現時点で利用できない場合、デフォルトで部分的な結果を返します。 データの一部を受信することになりますが、すべてのデータを受信して​​いないことさえわかりません。 これはデフォルトでどのように動作するかです。 同様の状況では、VictoriaMetrics はマークされたデータを部分として返します。

Thanos とは異なり、VictoriaMetrics ではデータが失われることはほとんどありません。 Prometheus から VictoriaMetrics への接続が中断されたとしても、Prometheus は受信した新しいデータを先行書き込みログ (サイズは 2 時間) に記録し続けるため、これは問題にはなりません。 VictoriaMetrics への接続を XNUMX 時間以内に復元すれば、データは失われません。 プロメテウス VictoriaMetrics への接続を復元した後にデータを追加できます.

XNUMX 時間後にのみデータをオブジェクト ストレージに書き込む Thanos とは異なり、Prometheus は、リモート書き込みプロトコルを使用して、VictoriaMetrics などのリモート ストレージにデータを自動的に複製します。 Prometheus のローカル ストレージを失うことを恐れる必要はありません。 突然ローカル ストレージを失った場合、最悪の場合、リモート ストレージに記録する時間がなかった最後の数秒のデータが失われることになります。

Kubernetes は Thanos とは異なり、クラスターを自動的に管理します。 VictoriaMetrics クラスター コンポーネントとは異なり、すべての Thanos コンポーネントを XNUMX つの Kubernetes クラスターに配置するのは困難です。

VictoriaMetrics では、新しいバージョンへの非常に簡単なアップデートが行われています。 VictoriaMetrics を停止し、バイナリを更新して起動するだけです。 SIGINT シグナルによって停止されると、すべての VictoriaMetrics バイナリは正常なシャットダウンを実行します。 必要なデータを正しく保存し、何も失われないように受信接続を正しく閉じます。 したがって、アップグレード時に何も失われることはありません。

VictoriaMetrics を使用すると、クラスターを非常に簡単に拡張できます。 必要なコンポーネントを追加するだけで、作業を続行できます。

ThanosとVictoriaMetricsの落とし穴について。

サノスには次のような落とし穴があります。 Prometheus は過去 3 時間のデータを保存する必要があります。 これらは SXNUMX のようにオブジェクト ストレージにまだ書き込まれていないため、紛失した場合は完全に失われます。

ストア・ゲートウェイ・コンポーネントとコンパクター・コンポーネントは、大きなオブジェクト・ストレージに多数の小さなファイルが保存されている場合、そのストレージを操作するために大量のメモリーを必要とする可能性があります。 ファイルの数とサイズが大きくなるほど、メタ情報を保存するために必要なストア ゲートウェイとコンパクターの RAM が増加します。 サノスは次の点に関して多くの問題を抱えています。 平均的な記録データ量でストア ゲートウェイとコンパクターがクラッシュする.

サノスは、所有するプロメテウスの量に応じて無期限に拡張できると宣伝されています。 これは実際には真実ではありません。 すべてのリクエストはクエリ コンポーネントを通過するため、すべてのストア ゲートウェイ コンポーネントとすべてのサイドカー コンポーネントを同時にポーリングする必要があり、そこからデータを取得して前処理します。 明らかに、リクエスト速度は最も遅い弱いリンク、最も遅いストア ゲートウェイ、または最も遅いサイドカーによって制限されます。

これらのコンポーネントの負荷が不均一になる可能性があります。 たとえば、XNUMX 秒あたり数百万のメトリクスを収集する Prometheus があるとします。 そして、毎秒数千のメトリクスを収集する Prometheus があります。 Prometheus は XNUMX 秒あたり数百万のメトリクスを収集するため、実行されるサーバーにはるかに高い負荷がかかります。 したがって、そこでは Sidecar の動作が遅くなります。 そして一般的に、そこではすべてがゆっくりと動作します。 そして、Query コンポーネントはそこから非常にゆっくりとデータを取得します。 したがって、クラスター全体のパフォーマンスは、この遅いサイドカーによって制限されます。

デフォルトでは、一部のサイドカーとストア ゲートウェイのいずれかが利用できない場合、Thanos は部分的なデータを提供します。 たとえば、サイドカーが世界中のさまざまなデータ センターに分散している場合、接続障害が発生し、コンポーネントが利用できなくなる可能性が大幅に高まります。 したがって、ほとんどの場合、知らないうちに部分的なデータを受け取ることになります。

VictoriaMetrics には落とし穴もあります。 最初の落とし穴は、VictoriaMetrics キャッシュに使用される RAM の量を制限するオプションです。 デフォルトでは、VictoriaMetrics が実行されているマシンの RAM の 60%、または Kubernetes の VictoriaMetrics ポッドの RAM の 60% に相当します。

この値を誤って変更すると、VictoriaMetrics のパフォーマンスが損なわれる可能性があります。 たとえば、値を低く設定しすぎると、データが VictoriaMetrics キャッシュに収まらなくなる可能性があります。 このため、彼女は追加の作業を行ってプロセッサとディスクに負荷をかける必要があります。 このオプションを大きくしすぎると、第一に、VictoriaMetrics がメモリ不足エラーでクラッシュする可能性が高まり、第二に、オペレーティング システムのメモリに残される RAM がほとんどなくなります。ファイルキャッシュ。 また、VictoriaMetrics はパフォーマンスをファイル キャッシュに依存しています。 これが十分でない場合、ディスクの負荷が大幅に増加する可能性があります。 したがって、絶対に必要な場合を除き、パラメータを変更しないでください。

1 番目のオプション。 これは、retentionPeriod です。デフォルトで XNUMX か月に設定されている期間です。 これは、VictoriaMetrics がデータを保存する時間の長さです。 この期間が経過すると、VictoriaMetrics はデータを削除します。

多くの人は、このパラメーターを使用せずに VictoriaMetrics を実行し、1 か月間データを記録します。 そして、なぜ前月のデータが消えてしまったのかと尋ねます。 デフォルトの保持期間は XNUMX か月であるためです。 したがって、正しい保持期間を知って設定する必要があります。

ユニークな機能を見てみましょう。

Thanos にはダウンサンプリングと呼ばれる機能があります。これは 5 分間隔と XNUMX 時間間隔です。 正常に動作していない。 Google で github の問題を調べてみると、このダウンサンプリングに関連する多くの問題があり、正しく動作しない場合やユーザーの期待どおりに動作しない場合があります。

Thanos には、Prometheus HA ペアのデータ重複排除機能があります。 XNUMX つの Prometheus が同じターゲットから同じメトリクスを収集し、Thanos がそれらを Object Storage に保存する場合。 VictoriaMetrics とは異なり、Thanos はこのデータを適切に重複排除できます。

Thanos には、Thanos の回路図にあったアラート コンポーネントがあります。 しかし彼は 運用環境での使用は推奨されません.

サノスには、サノスとプロメテウスが同じコードを共有しているという利点があります。 サノスとプロメテウスは同じ開発者によって開発されています。 サノスやプロメテウスを改良すれば、相手が勝ちます。

VictoriaMetrics の主な機能は MetricsQL です。 これらは PromQL 用の VictoriaMetrics 拡張機能であり、以前の大規模な監視ミーティングで話しました。

VictoriaMetrics は、さまざまなプロトコルを使用したデータの読み込みをサポートしています。 VictoriaMetrics は、Prometheus からのデータだけでなく、Influx、OpenTSDB、Graphite プロトコル経由でもデータを受け入れることができます。

VictoriaMetrics データは、Thanos や Prometheus と比較して、占有するスペースがはるかに少なくなります。

実際のデータを記録すると、Prometheus や Thanos と比較してディスク上のデータ サイズが 2 ～ 5 倍削減されるとユーザーは話します。

VictoriaMetrics のもう XNUMX つの利点は、速度が最適化されていることです。

インフラストラクチャのコストを見てみましょう。

Thanos の利点の XNUMX つは、データを比較的安価なオブジェクト ストレージに保存できることです。

オブジェクト ストレージにデータを保存する場合、データの書き込みおよび読み取り操作に対して料金を支払う必要があります (10 万操作あたり 10 ドル)。 オブジェクト ストレージにデータを書き込む場合、インターネットにデータをアップロードするためのホスティング費用を支払います。クラスターが AWS にない場合、AWS では無料です。 データを読み取る場合は、230 TB あたり 1 ～ XNUMX ドルの料金を支払います。 これは、Thanos クラスターの履歴データを頻繁にクエリする場合に重要になる可能性があります。

Thanos クラスターの場合、大量のメモリを必要とする Compact、Store Gateway、Query コンポーネント、および大量のデータ用の CPU のサーバーの料金を支払う必要があります。

VictoriaMetrics には次の費用がかかります。 GCE HDD ドライブにデータを保存すると、40 TB で 1 ドルになります。 VictoriaMetrics の場合、通常の HDD ドライブで十分であり、XNUMX 倍のコストがかかる SSD は必要ありません。 VictoriaMetrics は HDD 用に最適化されています。

VictoriaMetrics には、単一ノードまたはクラスター化されたコンポーネントのコンポーネント用のサーバーが必要です。Thanos コンポーネントとは異なり、必要な CPU と RAM が大幅に少なく、したがってコストも安くなります。

実装例。

Thanos は Gitlab に実装例を持っています。 Gitlab は完全に Thanos 上で実行されます。 しかし、すべてがそれほどスムーズに進むわけではありません。 それらを見てみると、 問題、そうすると、彼らは常にいくつかを持っていることがわかります サノスの運用上の問題: ストア ゲートウェイまたはクエリ コンポーネントに十分なメモリがありません。 常にメモリ量を増やす必要があります。

このため、これらの問題を解決するためのコストが増加します。

XNUMX 番目の実装は、より成功する可能性がありますが、Thanos の開発を開始した Improbable 社です。 彼らはサノスのソースコードを公開しました。 Improbable はゲームエンジンを開発する会社です。

VictoriaMetrics には公開された実装例があります。

• wix.com ウェブサイトビルダー
• Adidas は VictoriaMetrics を導入しており、前回の PromCon 2019 でもプレゼンテーションを行いました。
• TrafficStars - 広告ネットワーク
• Seznam.cz はチェコの人気のある検索エンジンです。

そして、今は名前を言えない無名企業もありました。 彼らは同意しませんでした。

• 某大手ゲーム開発会社。 私よりも大きい。ありえない。
• 大手グラフィックソフト開発会社。
• ロシアの大手銀行。
• VictoriaMetrics のテストに成功したヨーロッパの風力タービン メーカー。 このメーカーは、VictoriaMetrics を実装して、風力タービンから収集されたデータをセンサーごとに 50 秒あたり XNUMX サンプルの速度で監視しています。 各風力タービンには数百個のセンサーが付いています。 彼らには数百の風力タービンがあります。
• VictoriaMetrics を導入したいと考えているものの、まだ導入できていないロシアの航空会社。 私たちは彼らと契約段階にいます。

結論。

VictoriaMetrics と Thanos は同様の問題を解決しますが、方法は異なります。

• グローバルクエリビュー
• 水平スケーリング
• 任意の保持

ありがとう。

私たちはあなたをお待ちしています 電報チャンネル.

登録ユーザーのみがアンケートに参加できます。 ログインお願いします。

Prometheus の長期ストレージとして何を使用していますか?

• 視聴者の３８%がタノス6

• 視聴者の３８%がコーテックス0

• 視聴者の３８%がM3DB0

• 視聴者の３８%がビクトリアメトリクス7

• 視聴者の３８%がその他4

17 人のユーザーが投票しました。 16名のユーザーが棄権した。

出所： habr.com