statsdとgraphiteの高可用性、Webアクセス可能、スケーラブルな展開
HTMLデバイスで実行されているJSアプリをログに記録できるようにstatsd/graphiteを設定したいと思います（つまり、含まれている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が少ないほど良いです:)
- webアプリは共有NFSデータのみを読み取るため、Webアプリのスケーリングは明らかなようです（テストはしていませんが）。
だから私は誰かがしっかりしたstatsd/graphiteの展開のために共有する経験とベストプラクティスを持っているかどうか疑問に思いましたか？
コンシステントハッシュを使用したstatsdプロキシがあります。これにより、それぞれが独自のメトリック名のセットを使用する複数のstatsdアグリゲーター間でstatsdトラフィックを分散できます。これはアーキテクチャの重要なスケーラビリティ要素であり、statsdプロセスをスケーリングできます。
グラファイトもトリッキーですが、無限のスケールを必要とせず、サービスまたはその他の静的パラメーターによって細かいシャーディングを実行できることを願っています。
最も難しい部分はwebappのスケーリングであり、それは最も重いグラフクエリが何であるかに大きく依存します。ただし、最も難しいグラフのデータをいつでも事前に集計して、ほとんどの負荷を取り除くことができます。
私はこのすべての苦痛を避けるためにかなり長い間HostedGraphiteを使用してきました、これらの人はCarbon用に独自のRiakバックエンドを実装し、そこですべてのスケーリングを行いました。