Bioyino - 分散型のスケーラブルなメトリクス アグリゲータ

そこでメトリクスを収集します。 私たちもそうです。 指標も収集します。 もちろんビジネスにも必要です。 今日は、監視システムの最初のリンクである statsd 互換の集計サーバーについて説明します。 ビオイノ、なぜそれを書いたのか、そしてなぜブルーベックを放棄したのか。

以前の記事から (1, 2) ある時期まで、私たちは次の方法を使用してマークを収集していたことがわかります。 ブルーベック。 これは C で書かれています。コードの観点から見ると、プラグのように単純です (これは貢献したいときに重要です)。そして最も重要なのは、ピーク時に 2 万メトリック/秒 (MPS) のボリュームを処理できることです。問題なく。 ドキュメントには、4 万 MPS のサポートがアスタリスク付きで記載されています。 これは、Linux 上でネットワークを正しく構成すると、記載された数値が得られることを意味します。 (ネットワークをそのままにした場合にどれくらいの MPS が得られるかはわかりません)。 これらの利点にもかかわらず、ブルーベックについてはいくつかの深刻な苦情がありました。

請求項1。 プロジェクトの開発者である Github は、パッチと修正の公開、私たちのもの、そして (私たちだけでなく) PR の受け入れなど、プロジェクトのサポートを停止しました。 ここ数か月（2018 年 2 月から XNUMX 月にかけて）活動が再開されましたが、それまではほぼ XNUMX 年間、完全に平穏な状態が続いていました。 さらに、プロジェクトも開発中です Gihub の内部ニーズに対応、これは新機能の導入にとって重大な障害となる可能性があります。

請求項2。 計算の正確さ。 Brubeck は、合計 65536 個の値を集計のために収集します。 私たちの場合、一部のメトリクスでは、集計期間 (30 秒) 中に、さらに多くの値が到着する可能性があります (ピーク時は 1)。 このサンプリングの結果、最大値と最小値は役に立たないように見えます。 たとえば、次のようになります。

そのまま

どうあるべきだったのか

同じ理由で、金額は一般的に誤って計算されます。 ここに 32 ビット浮動小数点オーバーフローのバグを追加します。通常、一見無害なメトリクスを受信するとサーバーがセグメンテーション違反に陥り、すべてがうまくいきます。 ちなみにバグは修正されていない。

そして最後に、 クレームX。 この記事の執筆時点では、見つかった 14 個のほぼ動作する statsd 実装すべてにそれを提示する準備ができています。 いくつかの単一インフラストラクチャが成長しすぎて、4 万 MPS を受け入れるだけでは十分ではなくなったと想像してください。 あるいは、まだ成長していなくても、その指標はすでにあなたにとって非常に重要であるため、チャートの 2 ～ 3 分の短い下落でさえすでに重大な問題となり、マネージャーの間で克服できない憂鬱の発作を引き起こす可能性があります。 うつ病の治療は報われない仕事であるため、技術的な解決策が必要です。

まず、サーバー上の突然の問題がオフィスに精神医学的ゾンビの黙示録を引き起こさないようにするためのフォールト トレランスです。 4 つ目は、Linux ネットワーク スタックを深く掘り下げずに、必要なサイズまで「幅広く」静かに拡張することなく、XNUMX 万 MPS を超える値を受け入れられるようにスケーリングすることです。

スケーリングの余地があったため、フォールト トレランスから始めることにしました。 "について！ フォールトトレランス！ それは簡単だ、私たちにできる」と私たちは考え、2 つのサーバーを起動し、それぞれで brubeck のコピーを起動しました。 これを行うには、メトリクスを含むトラフィックを両方のサーバーにコピーし、さらにそのために書き込む必要がありました。 小さなユーティリティ。 これで耐障害性の問題は解決しましたが、あまりうまくいきませんでした。 最初はすべてがうまくいっているように思えました。各 brubeck は独自のバージョンの集計を収集し、30 秒ごとにデータを Graphite に書き込み、古い間隔を上書きします (これは Graphite 側で行われます)。 30 台のサーバーに突然障害が発生した場合でも、集約データの独自のコピーを備えた 2 台目のサーバーが常に存在します。 しかし、ここに問題があります。サーバーに障害が発生すると、グラフに「のこぎり」が表示されます。 これは、brubeck の 4 秒間隔が同期されておらず、クラッシュの瞬間にそのうちの XNUMX つが上書きされないという事実によるものです。 XNUMX 番目のサーバーが起動すると、同じことが起こります。 かなり許容範囲ですが、もっと良くしたいです！ スケーラビリティの問題も解決していません。 すべてのメトリクスは引き続き単一サーバーに「送信」されるため、ネットワーク レベルに応じて同じ XNUMX ～ XNUMX 万 MPS に制限されます。

この問題について少し考え、同時にシャベルで雪を掘ると、次のような明白なアイデアが思い浮かぶかもしれません。分散モードで動作できる statsd が必要です。 つまり、ノード間の時間とメトリクスの同期を実装するものです。 「もちろん、そのようなソリューションはおそらくすでに存在しているでしょう」と私たちは言い、Google に行きました…。 そして何も見つかりませんでした。 さまざまな statsd のドキュメントを読んだ後 (https://github.com/etsy/statsd/wiki#server-implementations 11.12.2017 年 XNUMX 月 XNUMX 日現在)、まったく何も見つかりませんでした。 どうやら、これらのソリューションの開発者もユーザーも、まだそれほど多くの指標に遭遇していないようです。そうでなければ、間違いなく何かを思いつくでしょう。

そして私たちは、Just for Fun ハカソンで書かれた「おもちゃ」の statsd - bioyino のことを思い出し (プロジェクトの名前は、ハッカソンの開始前にスクリプトによって生成されました)、独自の statsd が緊急に必要であることに気づきました。 何のために？

• 世界中に statsd クローンが少なすぎるため、
• 望ましい、または望ましいフォールト トレランスとスケーラビリティに近いものを提供できるため (サーバー間で集約されたメトリクスの同期や送信競合の問題の解決など)、
• brubeck よりも正確にメトリクスを計算できるため、
• より詳細な統計を自分で収集できるため、brubeck は事実上提供しませんでしたが、
• なぜなら、私は独自のハイパーパフォーマンス分散スケール ラボ アプリケーションをプログラムする機会があったからです。これは、別の同様のハイパーフォーのアーキテクチャを完全に繰り返すわけではありません。まあ、それだけです。

何に書きますか？ もちろんRustで。 なぜ？

• すでにプロトタイプのソリューションがあったため、
• なぜなら、記事の著者は当時既に Rust のことを知っていて、それをオープンソースに公開する機会を得て、実稼働用に何かを書きたいと熱望していたからです。
• GC を使用する言語は、受信するトラフィックの性質 (ほぼリアルタイム) により私たちには適しておらず、GC の一時停止は事実上許容できないため、
• C に匹敵する最大のパフォーマンスが必要なため
• なぜなら、Rust は恐れることのない同時実行性を提供しており、それを C/C++ で書き始めたら、ブルーベックよりもさらに多くの脆弱性、バッファ オーバーフロー、競合状態、その他の恐ろしい言葉が大量に発生することになるでしょう。

Rustに対する議論もありました。 同社にはRustでプロジェクトを作成した経験がなく、現在メインプロジェクトでRustを使用する予定もありません。 したがって、何もうまくいかないのではないかという深刻な懸念がありましたが、私たちはチャンスを賭けて試してみることにしました。

時は過ぎた...

数回の失敗を経て、最終的に最初の動作バージョンが完成しました。 どうしたの？ これが起こったのです。

各ノードは独自のメトリクスのセットを受信して​​蓄積しますが、最終的な集計に完全なセットが必要なタイプのメトリクスは集計しません。 ノードはある種の分散ロック プロトコルによって相互に接続されており、これにより、グレート ワンにメトリクスを送信する価値のあるノードの中から (ここで叫びました) XNUMX つだけを選択することができます。 この問題は現在、次の方法で解決されています。 領事しかし、将来的には著者の野望は次のとおりです。 自分 実装 Raft では、最も価値のあるノードがコンセンサス リーダー ノードになります。 コンセンサスに加えて、ノードは非常に頻繁に (デフォルトでは XNUMX 秒に XNUMX 回)、その秒内に収集できた事前に集約されたメトリクスの一部を隣接ノードに送信します。 スケーリングとフォールト トレランスが維持されていることがわかりました。各ノードは依然としてメトリクスの完全なセットを保持していますが、メトリクスはすでに集約されて TCP 経由で送信され、バイナリ プロトコルにエンコードされているため、UDP と比較して重複コストが大幅に削減されます。 受信メトリクスの数がかなり多いにもかかわらず、蓄積に必要なメモリは非常に少なく、CPU もさらに少なくなります。 圧縮率の高いメティクスの場合、これはわずか数十メガバイトのデータです。 追加のボーナスとして、burbeck の場合のように、Graphite では不必要なデータの書き換えが発生しません。

メトリックを含む UDP パケットは、単純なラウンド ロビンによってネットワーク機器上のノード間で不均衡になります。 もちろん、ネットワーク ハードウェアはパケットの内容を解析しないため、まったく知らないメトリクスは言うまでもなく、4 秒あたり 1M をはるかに超えるパケットを取得できます。 メトリクスが各パケットで一度に 2 つずつ送信されるわけではないことを考慮すると、この場所でパフォーマンスの問題が発生することは予想されません。 サーバーがクラッシュすると、ネットワーク デバイスはこの事実をすぐに (30 ～ XNUMX 秒以内に) 検出し、クラッシュしたサーバーをローテーションから削除します。 この結果、パッシブ (つまり、非リーダー) ノードは、チャート上のドローダウンに気付かずにオン/オフを切り替えることができます。 損失の最大値は、最後の XNUMX 秒で取得された指標の一部です。 リーダーの突然の喪失/シャットダウン/切り替えによっても軽度の異常が発生します (XNUMX 秒間隔はまだ同期していません)。ただし、ノード間に通信がある場合、たとえば同期パケットを送信することによって、これらの問題を最小限に抑えることができます。 。

内部構造について少し。 もちろん、アプリケーションはマルチスレッドですが、スレッド アーキテクチャは brubeck で使用されているものとは異なります。 brubeck のスレッドは同じであり、それぞれが情報の収集と集約の両方を担当します。 bioyino では、作業者はネットワーク担当者と集約担当者の 8 つのグループに分けられます。 この分割により、メトリクスのタイプに応じてアプリケーションをより柔軟に管理できます。集中的な集約が必要な場合はアグリゲータを追加し、ネットワーク トラフィックが大量にある場合はネットワーク フローの数を追加できます。 現在、当社のサーバーでは 4 つのネットワークと XNUMX つの集約フローで作業しています。

カウント (集計を担当) 部分は非常に退屈です。 ネットワーク フローによって満たされたバッファはカウント フロー間で分散され、その後解析されて集計されます。 要求に応じて、他のノードに送信するためのメトリクスが提供されます。 ノード間のデータ送信や Consul との連携を含むこれらすべては、フレームワーク上で非同期に実行されます。 東京.

開発中のはるかに多くの問題は、メトリクスの受信を担当するネットワーク部分によって引き起こされました。 ネットワーク フローを個別のエンティティに分離する主な目的は、フローにかかる時間を削減することでした。 ノー ソケットからデータを読み取ります。 非同期 UDP と通常の recvmsg を使用するオプションはすぐに消えてしまいました。XNUMX つ目はイベント処理にユーザー空間の CPU を大量に消費し、XNUMX つ目はコンテキスト スイッチが多すぎます。 したがって、現在使用されています recvmmsg 大きなバッファーを備えています（そして、警察官の皆さん、バッファーなど何の役にも立ちません！）。 通常の UDP のサポートは、recvmmsg が必要ない軽いケースのために予約されています。 マルチメッセージ モードでは、主なことを実現できます。つまり、ほとんどの場合、ネットワーク スレッドが OS キューをレイクし、ソケットからデータを読み取り、それをユーザー空間のバッファに転送し、満たされたバッファをユーザー空間のバッファに渡すように切り替えるのはごくまれです。アグリゲーター。 ソケット内のキューは実質的に蓄積されず、ドロップされたパケットの数も実質的に増加しません。

注意

デフォルト設定では、バッファ サイズは非常に大きく設定されています。 突然サーバーを自分で試してみることにした場合、少数のメトリクスを送信した後、それらのメトリクスが Graphite に到着せず、ネットワーク ストリーム バッファに残っているという事実に遭遇する可能性があります。 少数のメトリクスを処理するには、構成で bufsize と task-queue-size をより小さい値に設定する必要があります。

最後に、チャート愛好家向けのチャートをいくつか紹介します。

各サーバーの受信メトリック数に関する統計: 2 万 MPS 以上。

ノードの XNUMX つを無効にし、受信メトリクスを再配布します。

発信メトリクスに関する統計: 常に XNUMX つのノード (RAID ボス) のみが送信します。

さまざまなシステム モジュールのエラーを考慮した、各ノードの動作の統計。

受信メトリクスの詳細 (メトリクス名は非表示になります)。

次にこれらすべてをどうするつもりでしょうか? もちろん、コードを書いてください...! このプロジェクトは当初、オープンソースになる予定であり、その存続期間を通じてオープンソースであり続ける予定です。 私たちの当面の計画には、Raft の独自バージョンへの切り替え、ピア プロトコルの移植性の高いものへの変更、追加の内部統計、新しいタイプのメトリクス、バグ修正、その他の改善の導入が含まれます。

もちろん、PR の作成や問題点の作成、可能であれば対応、改善など、プロジェクトの開発に協力していただくことは誰でも大歓迎です。

そうは言っても、皆さん、象を買ってください！

出所： habr.com