グラファイトのカーボンアグリゲーターが同じ仕事を行えるのに、なぜstatsdを使用するのですか？
複数のサーバーのメトリックを表示するためのGraphiteグラフ作成ツールを調査してきましたが、すべてのメトリックデータを最初にStatsDに送信することが「推奨」の方法のようです。 StatsDはデータを集約し、それをグラファイト（または、カーボン）に送信します。
私の場合、サーバー全体のメトリックの合計や平均などの単純な集計を行い、それをグラファイトでプロットしたいと思います。 Graphiteには、これを実行できるCarbonアグリゲーターが付属しています。
StatsDは、私が話している種類の集約さえ提供しません。
私の質問は-ユースケースにstatsdを使用する必要がありますか？ここに足りないものはありますか？
StatsDはUDP上で動作します。これにより、carbon-aggregator.pyの応答が遅くなり、アプリケーションに遅延が発生するリスクがなくなります。言い換えれば、疎結合。
StatsDはインバウンドメトリックのサンプリングをサポートしています。これは、アグリゲーターがすべてのデータポイントの100％を使用して記述統計を計算したくない場合に役立ちます。大量のコードセクションの場合、StatsDが過負荷にならないように、0.5％〜1％のサンプルレートを使用するのが一般的です。
StatsDには broad client-side がサポートされています。
tldr：サーバー固有の合計または平均を確認したい場合は、おそらくstatsd（または carbon-c-relay ）が必要です。
カーボンアグリゲーターは、複数のメトリックからの値を単一の出力メトリックに集約するように設計されており、通常はグラフのレンダリングパフォーマンスを向上させます。 statsdは、単一のメトリックで複数のデータポイントを集約するように設計されています、そうでない場合、グラファイトは最小ストレージに報告された最後の値のみを格納します解決。
statsdの例：グラファイトstorage-schemas.confファイルの最小保持期間は10秒（デフォルト）で、アプリケーションは10秒ごとに約100データポイントを- services.login.server1.count値が1の場合、statsdを指定しないと、グラファイトは各10秒バケットで受信した最後のカウントのみを保存します。 100番目のメッセージが受信された後、他の99個のデータポイントは破棄されます。ただし、アプリケーションとグラファイトの間にstatsdを配置すると、合計をグラファイトに送信する前に100個のデータポイントがすべて合計されます。そのため、statsdを使用しない場合、グラフはifが10秒間隔でログインしたことのみを示します。 statsdを使用すると、how manyその間隔中にログインが発生したことを示します。 （ たとえば ）
カーボンアグリゲーターの例：200の異なるメトリックを報告する200の異なるサーバーがあると仮定します（services.login.server1.response.time、services。 login.server2.response.time、etcetera）。オペレーションダッシュボードには、グラファイトクエリweightedAverage（services.login.server * .response.time、services.login.server * .response.count、2）を使用して、すべてのサーバーの平均のグラフを表示します。残念ながら、このグラフのレンダリングには10秒かかります。この問題を解決するには、カーボンアグリゲータールールを追加して、すべてのサーバーの平均を事前計算し、値を新しいメトリックに保存します。ダッシュボードを更新して、単一のメトリックをプルするだけです（例：services.login.response.time）。新しいメトリックはほぼ瞬時にレンダリングされます。
サイドノート：
storage-aggregation.confの集約ルールはstorage-schemas.confのすべてのストレージ間隔に適用されますexcept各保持文字列の最初（最小）の保持期間。カーボンアグリゲーターを使用して、その最初の保持期間のメトリック内のデータポイントを集約することができます。残念ながら、aggregation-rules.confは正規表現パターンではなく「blob」パターンを使用します。そのため、すべてのパスの深さと集計タイプに対して個別のaggregation-rules.confファイルエントリを追加する必要があります。 statsdの利点は、メトリックを送信するクライアントが集約パスをメトリックパスでエンコードするのではなく、集約タイプを指定できることです。これにより、メトリックパスの深さに関係なく、その場で新しいメトリックを柔軟に追加できます。新しいメトリックを追加したときに自動的にstatsdのような集約を行うようにCarbon-aggregatorを構成したい場合、aggregation-rules.confファイルは次のようになります。
<n1>.avg (10)= avg <n1>.avg$ <n1>.count (10)= sum <n1>.count$ <n1>.<n2>.avg (10)= avg <n1>.<n2>.avg$ <n1>.<n2>.count (10)= sum <n1>.<n2>.count$ <n1>.<n2>.<n3>.avg (10)= avg <n1>.<n2>.<n3>.avg$ <n1>.<n2>.<n3>.count (10)= sum <n1>.<n2>.<n3>.count$ ... <n1>.<n2>.<n3> ... <n99>.count (10)= sum <n1>.<n2>.<n3> ... <n99>.count$注：グラファイト0.10+（現在のプレリリース）では末尾の「$」は不要です githubに関連するパッチがあります および 集計ルール の標準ドキュメントです
weightedAverage関数は、グラファイト0.10で新しく追加されましたが、通常、負荷が均等に均衡している限り、averageSeries関数は非常に類似した数値を提供します。処理速度が遅く、リクエスト数が少ないサーバーがある場合や、正確さを求めるだけの場合でも、グラファイト0.9で加重平均を計算できます。次のようなより複雑なクエリを作成する必要があります。
divideSeries(sumSeries(multiplySeries(a.time,a.count), multiplySeries(b.time,b.count)),sumSeries(a.count, b.count))クライアントボックスでstatsdを実行すると、ネットワーク負荷も軽減されます。ただし、理論的には、クライアント側でもカーボンアグリゲーターを実行できます。ただし、statsdクライアントライブラリのいずれかを使用する場合は、サンプリングを使用して、アプリケーションマシンのCPUの負荷を減らすこともできます（ループバックudpパケットの作成など）。さらに、statsdは、単一の入力メトリック（合計、平均、最小、最大など）で複数の異なる集約を自動的に実行できます。
各アプリサーバーでstatsdを使用して応答時間を集計し、カーボンアグリゲーターを使用してグラファイトサーバーでそれらの値を再集計すると、リクエストではなくアプリサーバーによって重み付けされた平均応答時間になります。明らかに、これは平均、またはtop_90集計ルールを使用して集計する場合にのみ重要であり、min、max、sumではありません。また、負荷が不均衡な場合にのみ意味があります。例として、100台のサーバーのクラスターがあり、突然1台のサーバーがトラフィックの99％を送信すると仮定します。その結果、応答時間はその1台のサーバーでは4倍になりますが、他の99台のサーバーでは安定したままです。クライアント側の集約を使用する場合、全体的なメトリックは約3％しか上がりません。ただし、単一のサーバー側のカーボンアグリゲーターですべての集計を行うと、全体のメトリックは約300％増加します。
carbon-c-relay は、基本的にcで記述されたカーボンアグリゲーターのドロップイン置換です。パフォーマンスと正規表現ベースのマッチングルールが改善されました。つまり、statsdスタイルのデータポイント集約とカーボンリレースタイルのメトリック集約の両方、および多層集約のようなその他のきちんとしたものを、すべて同じ単純な正規表現ベースの構成ファイルで実行できるということです。
カーボンキャッシュの代わりに cyanite バックエンドを使用すると、cyaniteはメモリ内でイントラメトリック平均化を行います（ version 0.5.1 の時点）または読み取り時（バージョン<0.1.3アーキテクチャ）。
Carbon Aggregatorが必要なものすべてを提供する場合、それを使用しない理由はありません。 2つの基本的な集計関数（合計と平均）があり、実際、これらはStatsDの対象ではありません。 （履歴についてはわかりませんが、Carbonアグリゲーターがすでに存在し、StatsDの作成者が機能を複製したくないのかもしれません。）UDPを介したデータの受信もCarbonによってサポートされているため、見逃すのはサンプリングだけです、平均化によって集計する場合は関係ありません。
StatsDは、追加の集計値を追加することでさまざまなメトリックタイプをサポートします（タイマーの場合：平均、下限、上限、上限のXパーセンタイルなど）。私はそれらが好きですが、あなたがそれらを必要としないなら、カーボンアグリゲーターも行く良い方法です。
私はCarbonアグリゲーターとStatsD（および Bucky 、PythonのStatsD実装）のソースコードを見てきましたが、それらはすべて非常に単純であるため、リソースの使用やパフォーマンスについて心配することはありませんいずれかの選択。
カーボンアグリゲーターとstatsdは、互いに素な機能セットをサポートしているようです：
- statsdはレート計算と合計をサポートしますが、平均値はサポートしません
- カーボンアグリゲーターは平均化をサポートしていますが、レート計算はサポートしていません。