scale - 複数のサーバーでstatsdをスケーリングする

Question

statsdとgraphiteを使用するアーキテクチャをレイアウトしています。グラファイトがどのように機能し、単一のstatsdサーバーがどのようにグラファイトと通信できるかを理解しています。statsdサーバーをスケールアウトするためにアーキテクチャとセットアップがどのように機能するのか疑問に思っています。複数のノードのstatsdサーバーがあり、次に1つの中央のstatsdサーバーがgraphiteにプッシュしますか？statsdのスケールアウトについては何も見つからなかったようです。複数のstatsdサーバーを作成する方法についてのアイデアをいただければ幸いです。

Answer 1

私は今同じ問題を扱っています。同じ名前のキーは異なるstatsdsになり、誤って集約されるため、複数のstatsds間で単純な負荷分散を行うことは明らかに機能しません。

ただし、スケーリングが必要な環境でstatsdを使用するためのオプションがいくつかあります。

• statsdのドキュメントで説明されているように、カウンターメトリックにクライアント側のサンプリングを使用します（つまり、すべてのイベントをstatsdに送信する代わりに、10番目ごとのイベントのみを送信し、statsdに10を掛けます）。欠点は、メトリックごとに適切なサンプリングレートを手動で設定する必要があることです。サンプリングする値が少なすぎると、結果が不正確になります。サンプリングしすぎると、（単一の）statsdインスタンスが強制終了されます。

• メトリック名で異なるstatsdsにシャーディングするカスタムロードバランサーを構築し、集約の破損の問題を回避します。それらのそれぞれは、Graphiteに直接書き込むことができます。

• イベントをローカルでカウントし、それらをまとめてstatsdに送信するだけのstatsdクライアントを構築します。これにより、statsdに向かうトラフィックが大幅に削減され、一定になります（サーバーを追加しない限り）。データをstatsdに送信する期間が、statsd自体のフラッシュ期間よりもはるかに短い限り、同様に正確な結果が得られるはずです。

• 私が本番環境で大成功を収めて実装した最後のポイントのバリエーション：複数の（私の場合はローカルの）statsdの最初のレイヤーを使用します。これにより、すべてが1つの中央のstatsdに集約され、Graphiteと通信します。statsdsの最初のレイヤーは、2番目のレイヤーよりもはるかに短いフラッシュ時間を必要とします。これを行うには、statsdからstatsdへのバックエンドが必要になります。私はまさにこの問題に直面したので、可能な限りネットワーク効率を高めようとする問題を作成しました：https ://github.com/juliusv/ne-statsd-backend

現状では、残念ながらstatsdは管理可能な方法でスケーリングするようには設計されていません（いいえ、サンプリングレートを手動で調整することは「管理可能」とは思われません）。ただし、上記の回避策は、問題が解決しない場合に役立ちます。

Answer 2

私が見た実装のほとんどは、次のようなサーバーごとのメトリックを使用しています。<env>.applications.<app>.<server>.<metric>

このアプローチでは、各ボックスにローカルstatsdインスタンスを配置し、UDPをローカルで実行し、statsdにその集計をgraphiteに公開させることができます。

サーバーごとのメトリックが本当に必要ない場合は、次の2つの選択肢があります。

1. 視覚化レイヤーで関連するメトリックを結合します（例：graphitiを構成することにより）
2. それを処理するために炭素凝集を使用してください

Answer 3

F5 BigIPのようなハードウェアロードバランサーにアクセスでき（これを行うOSSソフトウェア実装があると思います）、メトリックに各ホストのホスト名が含まれている場合（つまり、「appname.servername」などをカウントしている場合）。 foo.bar.baz "およびそれらをGraphiteレベルで集約）送信元アドレスアフィニティ負荷分散を使用できます-すべてのトラフィックを1つの送信元アドレスから同じ宛先ノードに（妥当なタイムアウト内で）送信します。したがって、各メトリック名が1つのソースホストのみからのものである限り、これにより目的の結果が得られます。