statsdとグラファイトの高可用性、Webアクセスおよびスケーラブルな展開

statsd / graphiteをセットアップして、HTMLデバイスで実行されているJSアプリをログに記録できるようにします（つまり、収容されたLAN環境ではなく、直接制御できない大量の着信データがある場合）。

私の制約：

• エントリポイントはHTTPを話す必要があります：これは単純なHTTP-to-UDP-statsdプロキシ（たとえば、githubのhttpstatsd）によって解決されます
• 単一のサーバーの障害に抵抗する必要があります（マーフィーの法則と戦うために:)
• 水平方向にスケーラブルでなければなりません：webscale、baby！:)
• アーキテクチャは可能な限りシンプル（かつ安価）に保つ必要があります
• 私のサーバーは仮想マシンです
• データファイルはファイラーアプライアンスに保存されます（NFSを使用）
• tcp / udpハードウェアロードバランサーを自由に使用できます

要するに、データパス：[client]-（http）-> [http2statsd]-（udp）-> [statsd]-（tcp）-> [graphite]-（nfs）-> [filer]

これまでの私の調査結果：

• http2statsd部分のスケーリングは簡単です（ステートレスデーモン）
• statsd部分のスケーリングは簡単ではないようです（sum、avg、min、maxなどの集計データのグラファイトで一貫性のない値になると思います）。HTTPデーモンがキーを分割するために一貫したハッシュを行わない限り。たぶんアイデア...（しかし、HAの質問があります）
• グラファイト部分のスケーリングは、シャーディング（カーボンリレーを使用）で実行できます（ただし、HAの問題も解決しません）。明らかに、いくつかのささやきインスタンスは同じNFSファイルを書き込むべきではありません。
• ファイラー部分のスケーリングは問題の一部ではありません（ただし、IOが少ないほど良いです:)
• 共有NFSデータのみを読み取るため、webappのスケーリングは明らかです（私はテストしていませんが）。

だから、誰もが安定したstatsd /グラファイト展開のために共有する経験とベストプラクティスを持っているのだろうかと思っていましたか？

一貫したハッシュを使用するstatsdプロキシがあり、それぞれが独自のメトリック名のセットを使用して、複数のstatsdアグリゲーター間でstatsdトラフィックを拡散できます。これは、アーキテクチャの重要なスケーラビリティ要素であり、statsdプロセスをスケーリングできます。

グラファイトも扱いにくいですが、うまくいけば無限のスケールが不要になり、サービスやその他の静的パラメーターによる細かいシャーディングができるようになります。

最も難しい部分はwebappのスケーリングであり、最も重いグラフクエリに大きく依存します。ただし、最も困難なグラフのデータをいつでも事前集計して、ほとんどの負荷を取り除くことができます。

HostedGraphiteをかなり長い間使用してこの痛みをすべて回避してきました。これらの人はCarbonに独自のRiakバックエンドを実装し、そこですべてのスケーリングを行っています。