VictoriaMetrics とプライベート クラウドのモニタリング。 パベル・コロバエフ

VictoriaMetrics は、時系列の形式でデータを保存および処理するための高速でスケーラブルな DBMS です (レコードは、時間と、この時間に対応する一連の値で構成されます。たとえば、センサーやステータスの定期的なポーリングによって取得されます)。メトリクスのコレクション）。

私の名前はコロバエフ・パベルです。 DevOps、SRE、LeroyMerlin、すべてはコードのようなものです。それはすべて私たちに関するものです。私と他の LeroyMerlin 従業員についてです。

https://bit.ly/3jf1fIK

OpenStackをベースにしたクラウドがあります。 技術レーダーへの小さなリンクがあります。

これは、Kubernetes ハードウェアだけでなく、OpenStack とロギングのすべての関連サービス上に構築されています。

これは私たちが開発中に持っていたスキームです。 これらすべてを開発していたとき、K8s クラスター自体の内部にデータを保存する Prometheus オペレーターがありました。 大まかに言えば、彼はこするべきものを自動的に見つけて足の下に置きます。

何かが起こった場合に、何がどこで起こったかを理解する必要があるため、すべてのデータを Kubernetes クラスターの外に移動する必要があります。

XNUMX つ目の解決策は、サードパーティの Prometheus を使用している場合、フェデレーション メカニズムを通じて Kubernetes クラスターにアクセスするときにフェデレーションを使用することです。

しかし、ここには小さな問題がいくつかあります。 私たちの場合、問題はメトリクスが 250 あったときに始まり、メトリクスが 000 になったときに、そのように作業することはできないことに気づきました。 Scrape_timeout を 400 秒に増やしました。

なぜこんなことをしなければならなかったのでしょうか？ プロメテウスはフェンスの先頭からタイムアウトのカウントを開始します。 データがまだ流れているかどうかは問題ではありません。 この指定された期間内にデータがマージされず、http 経由でセッションが閉じられなかった場合、セッションは失敗したとみなされ、データは Prometheus 自体に取り込まれません。

データの一部が欠落したときに得られるグラフは誰もがよく知っています。 スケジュールが乱れており、私たちはこれに満足していません。

次のオプションは、同じフェデレーション メカニズムを介した XNUMX つの異なる Prometheus に基づくシャーディングです。

たとえば、それらを取得し、名前でシャード化するだけです。 これも使えますが、次に進むことにしました。

これらのシャードを何らかの方法で処理する必要があります。 プロミキシを使用すると、シャード領域に移動してデータを増倍できます。 XNUMX つのシャードを XNUMX つのエントリ ポイントとして使用します。 これはプロキシ経由で実装できますが、それでも難しすぎます。

最初のオプションは、フェデレーション メカニズムが非常に遅いため、フェデレーション メカニズムを放棄することです。

Prometheus 開発者は明確に、「皆さん、メトリクスの長期保存はサポートしないので、別の TimescaleDB を使用してください」と言っています。 これは彼らの仕事ではありません。

すべてをXNUMXか所に保管しないように、外に降ろす必要があるものを紙に書き留めます。

2020 番目の欠点はメモリの消費です。 はい、XNUMX 年には数ギガバイトのメモリに XNUMX ペニーのコストがかかると多くの人が言うことは理解していますが、それでもです。

これで、開発環境と本番環境が完成しました。 開発環境では、9 メトリクスで約 350 ギガバイトになります。 本番環境では、000 GB と 14 メトリクスを少し超える程度になります。 同時に、保持時間はわずか 780 分です。 これは悪いです。 そして今からその理由を説明します。

つまり、35 万のメトリクスを使用して計算を行い、設計段階で 37 ～ 4 ギガバイトのメモリを得ることができ、すでにそれに近づいています。 しかし、すでに 90 万のメトリクスには約 XNUMX GB のメモリが必要です。 つまり、Prometheus 開発者によって提供された式を使用して計算されました。 私たちは相関関係を調べ、監視のためだけにサーバーに数百万も払いたくないことに気づきました。

マシンの数を増やすだけでなく、仮想マシン自体の監視も行います。 したがって、仮想マシンが増えれば増えるほど、さまざまな種類のメトリクスも増えます。メトリクスに関しては、クラスタが特別に増加することになります。

ディスク容量に関しては、すべてがそれほど悪いわけではありませんが、改善したいと考えています。 15 日間で合計 120 ギガバイトを受け取りました。そのうち 100 ギガバイトは圧縮データ、20 ギガバイトは非圧縮データですが、常にもっと少なくしたいと考えています。

したがって、もう XNUMX 点注意してください。これはリソースの大量消費ですが、監視クラスターが OpenStack を管理するクラスターよりも多くのリソースを消費したくないため、それでも節約したいと考えています。

Prometheus にはもう 20 つの欠点があり、これは私たち自身で特定しました。これは、少なくともある種のメモリ制限です。 プロメテウスの場合は、そのようなひねりがまったくないため、すべてがはるかに悪化します。 Docker で制限を使用することもオプションではありません。 RAF が突然低下し、30 ～ XNUMX ギガバイトがある場合、回復するまでに非常に長い時間がかかります。

これは、Prometheus が私たちに適さないもう XNUMX つの理由です。つまり、メモリ消費を制限することができません。

このような計画を立てることも可能でしょう。 HA クラスターを構成するには、このスキームが必要です。 私たちは、メトリクスを保存しているサーバーがクラッシュした場合でも、メトリクスをいつでもどこでも利用できるようにしたいと考えています。 したがって、そのようなスキームを構築する必要があります。

このスキームでは、シャードが重複し、それに応じて消費されるリソースのコストも重複することになります。 ほぼ水平にスケーリングできますが、それでもリソースの消費は地獄のようになります。

私たちが自分自身で書き留めた形式でのデメリットの順序:

• 外部からメトリクスをアップロードする必要があります。
• リソースの消費量が多い。
• メモリ消費を制限する方法はありません。
• 複雑でリソースを大量に消費する HA の実装。

私たち自身としては、保管施設としてのプロメテウスから離れることにしました。

私たちは自分たちに必要な追加の要件を特定しました。 これ：

• これは promql のサポートです。クエリやアラートなど、Prometheus 用に多くのことがすでに書かれているからです。
• そして、Grafana があります。これはバックエンドとして Prometheus 用にまったく同じ方法ですでに書かれています。 ダッシュボードを書き換えたくありません。
• 通常の HA アーキテクチャを構築したいと考えています。
• 私たちはあらゆるリソースの消費を削減したいと考えています。
• もう一つ小さなニュアンスがあります。 各種クラウドメトリクス収集システムは利用できません。 これらの指標に何が当てはまるかはまだわかりません。 そして、そこには何でも飛んでくる可能性があるため、ローカルな配置に限定する必要があります。

選択肢はほとんどありませんでした。 私たちが経験したことをすべて集めました。 私たちは統合セクションの Prometheus ページを見て、大量の記事を読み、そこに何があるかを確認しました。 そして私たち自身も、Prometheus の代替として VictoriaMetrics を選択しました。

なぜ？ なぜなら：

• promql を知っている。
• モジュラーアーキテクチャがあります。
• Grafana を変更する必要はありません。
• そして最も重要なことは、おそらく社内でメトリクス ストレージをサービスとして提供することになるため、ユーザーが何らかの制限された方法でクラスターのすべてのリソースを使用できるように、さまざまな種類の制限を事前に検討していることです。マルチテナントになるということです。

最初の比較をしてみましょう。 同じ Prometheus をクラスター内に取り込み、外部の Prometheus がそこに移動します。 リモート書き込み VictoriaMetrics 経由で追加します。

ここで、VictoriaMetrics による CPU 消費量のわずかな増加が確認されたことをすぐに留保します。 VictoriaMetrics wiki には、どのパラメータが最適であるかが記載されています。 私たちはそれらをチェックしました。 CPU 消費量が大幅に削減されました。

私たちの場合、Kubernetes クラスター内にある Prometheus のメモリ消費量は大幅には増加しませんでした。

同じデータの XNUMX つのデータ ソースを比較します。 Prometheus でも、同じ欠落データが見られます。 VictoriaMetrics ではすべてが順調です。

ディスク容量のテスト結果。 私たちプロメテウスは合計 120 ギガバイトを受け取りました。 VictoriaMetrics では、すでに 4 日あたり XNUMX ギガバイトを受信して​​います。 私たちがプロメテウスで見慣れているものとは少し異なるメカニズムがあります。 つまり、データは XNUMX 日、つまり XNUMX 分ですでに十分に圧縮されています。 データは後で失われるという事実にもかかわらず、それらはすでに XNUMX 日、XNUMX 分で十分に刈り取られています。 その結果、ディスク容量を節約できました。

メモリリソースの消費も節約します。 テスト時には、8 コア、24 GB の仮想マシンに Prometheus をデプロイしました。 プロメテウスはほとんどすべてを食べます。 彼はOOMキラーに倒れた。 同時に、900 のアクティブなメトリクスのみが注入されました。 これは 000 秒あたり約 25 ～ 000 メトリクスです。

VictoriaMetrics は、8 GB の RAM を搭載したデュアルコア仮想マシンで実行しました。 8GB マシンでいくつかのことをいじることで、VictoriaMetrics をうまく動作させることができました。 最終的には 7 GB に抑えました。 同時に、コンテンツ、つまりメトリクスの配信速度は Prometheus よりもさらに高速でした。

CPUはPrometheusに比べて格段に性能が良くなりました。 ここで、Prometheus は 2,5 コアを消費しますが、VictoriaMetrics は 0,25 コアのみを消費します。 開始時 - 0,5 コア。 結合すると XNUMX つのコアに到達しますが、これは非常にまれです。

私たちの場合、お金を節約したかったという明らかな理由から、VictoriaMetrics を選択することになりました。

メトリクスのアップロードとリソースの大量消費という XNUMX つの点をすぐに取り消してみましょう。 そして、自分たちに残っているXNUMXつのポイントを決めるだけです。

ここですぐに予約します。VictoriaMetrics をメトリクスのストレージと見なします。 ただし、VictoriaMetrics をすべての Leroy のストレージとして提供する可能性が高いため、このクラスターを使用するユーザーを制限して、クラスターを提供しないようにする必要があります。

時間、データ量、実行時間によって制限できる素晴らしいパラメーターがあります。

メモリ消費を制限できる優れたオプションもあります。これにより、通常の動作速度と適切なリソース消費を実現できるバランスを見つけることができます。

もう XNUMX 点マイナスします。つまり、点を取り消します。メモリ消費を制限することはできません。

最初の反復では、VictoriaMetrics の単一ノードをテストしました。 次に、VictoriaMetrics クラスター バージョンに進みます。

ここでは、実行する対象と消費するリソースに応じて、VictoriaMetrics 内のさまざまなサービスを自由に分離できます。 これは非常に柔軟で便利なソリューションです。 私たちはこれを自分たちに使いました。

VictoriaMetrics クラスター バージョンの主なコンポーネントは vmstsorage です。 それらは N 個存在する可能性があります。 私たちの場合、これまでのところそのうちの2つがあります。

そしてvminsertがあります。 これは、次のことを可能にするプロキシ サーバーです。説明したすべてのストレージ間でシャーディングを調整し、レプリカも許可します。つまり、シャーディングとレプリカの両方を持つことになります。

Vminsert は、Prometheus の OpenTSDB、Graphite、InfluxDB、remoteWrite プロトコルをサポートします。

vmselect もあります。 その主なタスクは、vmstorage に移動し、そこからデータを受信し、このデータを重複排除してクライアントに渡すことです。

vmagent という素晴らしいものがあります。 私たちは彼女のことが本当に好きです。 Prometheus とまったく同じように構成でき、すべてを Prometheus とまったく同じように実行できます。 つまり、さまざまなエンティティやサービスからメトリックを収集し、それらを vminsert に送信します。 そうすれば、すべてはあなた次第です。

もう XNUMX つの優れたサービスは vmalert です。これを使用すると、VictoriaMetrics をバックエンドとして使用し、処理されたデータを vminsert から受信して vmselect に送信できます。 ルールだけでなくアラート自体も処理します。 アラートの場合は、alertmanager を通じてアラートを受信します。

wmauth コンポーネントがあります。 これをマルチテナンシー バージョンのクラスターの認証システムとして使用するかどうか (まだ決定していません)。 PrometheusのremoteWriteをサポートしており、URL、つまり書き込みできるかできないかのXNUMX番目の部分に基づいて認証できます。

vmbackup、vmrestore もあります。 これは本質的に、すべてのデータの復元とバックアップです。 S3、GCS、ファイルを実行できます。

クラスターの最初の反復は隔離中に行われました。 当時はレプリカがなかったため、反復は XNUMX つの異なる独立したクラスターで構成され、remoteWrite 経由でデータを受信しました。

ここで予約しておきますが、VictoriaMetrics シングル ノードから VictoriaMetrics クラスター バージョンに切り替えたとき、消費されたリソースは同じままでした。つまり、主なリソースはメモリでした。 これは、データ、つまりリソー​​ス消費がどのように分散されたかをほぼ示しています。

ここにはレプリカがすでに追加されています。 これらすべてを XNUMX つの比較的大きなクラスターに結合しました。 すべてのデータはシャーディングされ、レプリケートされます。

クラスター全体には N 個のエントリー ポイントがあります。これは、Prometheus が HAPROXY 経由でデータを追加できることを意味します。 ここにこのエントリポイントがあります。 このエントリ ポイントを通じて、Grafana からログインできます。

この例の場合、HAPROXY は、プロキシがこのクラスター内のサービスを選択、挿入、およびその他のサービスを行う唯一のポートです。 私たちの場合、VictoriaMetrics クラスターが実行される仮想マシン自体が同じクラウド プロバイダーの異なるゾーン、つまりクラウドの内部ではなく外部に配置されているため、XNUMX つのアドレスを作成することは不可能であり、いくつかのエントリ ポイントを作成する必要がありました。 。

警報が出ています。 私たちはそれを使っています。 Prometheus のアラートマネージャーを使用します。 弊社では、アラート配信チャネルとして Opsgenie と Telegram を使用しています。 Telegram では、開発者からの情報、場合によっては製品版からの情報が流入しますが、ほとんどはエンジニアが必要とする統計的な情報です。 そして、オプスジェニーは重要です。 これらは電話、インシデント管理です。

永遠の疑問「監視は誰がするのか？」 この場合、各ノードで vmagent を使用するため、監視は監視自体を監視します。 また、当社のノードは同じプロバイダーの異なるデータセンターに分散されているため、各データセンターは独自のチャネルを持ち、独立しており、たとえスプリットブレインが到着したとしてもアラートを受信します。 はい、それらはさらに多くなるでしょうが、何も受信しないよりは、より多くのアラートを受信した方が良いでしょう。

リストの最後は HA 実装です。

さらに、VictoriaMetrics コミュニティとのコミュニケーションの経験にも注目したいと思います。 とてもポジティブな結果になりました。 男たちは反応が良い。 彼らは提供されたすべてのケースを徹底的に調査しようとします。

GitHub でイシューを開始しました。 それらは非常に迅速に解決されました。 完全に解決されていない問題がさらにいくつかありますが、この方向に向けた作業が進行中であることがコードからすでにわかります。

反復中に私にとって最も苦痛だったのは、ノードをシャットダウンすると、最初の 30 秒間、vminsert がバックエンドが存在しないことを理解できないことでした。 これで決まりました。 そして文字通り XNUMX ～ XNUMX 秒で、残りのすべてのノードからデータが取得され、リクエストはその欠落しているノードの待機を停止します。

ある時点で、私たちは VictoriaMetrics を VictoriaMetrics オペレーターにしたいと考えていました。 私たちは彼を待ちました。 私たちは現在、Prometheus オペレーターに付属のルールを非常に積極的に使用しているため、VictoriaMetrics オペレーターがすべての事前計算ルールなど Prometheus を受け入れるためのフレームワークを積極的に構築しています。

クラスターの実装を改善するための提案があります。 上記でそれらの概要を説明しました。

そして本当にダウンサンプリングしたいのです。 私たちの場合、ダウンサンプリングは傾向を表示するためにのみ必要です。 大まかに言えば、XNUMX 日の測定基準は XNUMX つあれば十分です。 こうした傾向は、XNUMX 年、XNUMX 年、XNUMX 年、XNUMX 年にわたって必要です。 そして、XNUMX つのメトリック値で十分です。

• 私たちも、一部の同僚と同様に、Prometheus を使用する際の痛みを知っていました。
• 私たちは VictoriaMetrics を自分たちで選びました。
• 垂直方向と水平方向の両方に非常によく拡張されます。
• さまざまなコンポーネントをクラスター内のさまざまな数のノードに分散したり、メモリによってコンポーネントを制限したり、メモリを追加したりできます。

VictoriaMetrics はとても気に入ったので、自宅でも使用するつもりです。 これが昔も今もそうなったものです。

https://t.me/VictoriaMetrics_ru1

VictoriaMetrics チャット、私の連絡先、LeroyMerlin 技術レーダー用のいくつかの QR コード。

出所： habr.com