複数のサーバーからのメトリックを表示するための Graphite グラフ作成ツールを調査してきましたが、最初にすべてのメトリック データを StatsD に送信することが「推奨される」方法のようです。StatsD はデータを集計し、それをグラファイト (またはカーボン) に送信します。
私の場合、サーバー全体のメトリックの合計や平均などの単純な集計を行い、それをグラファイトにプロットしたいと考えています。グラファイトには、これを行うことができるカーボンアグリゲーターが付属しています。
StatsD は、私が話している種類の集計さえ提供しません。
私の質問は - 私のユースケースに statsd を使用する必要がありますか? ここに欠けているものはありますか？
StatsD は UDP を介して動作します。これにより、carbon-aggregator.py の応答が遅くなり、アプリケーションに遅延が生じるリスクがなくなります。つまり、疎結合です。
StatsD はインバウンド メトリックのサンプリングをサポートしています。これは、アグリゲーターがすべてのデータ ポイントを 100% 取得して記述統計を計算したくない場合に役立ちます。大量のコード セクションでは、StatsD が過負荷にならないように、0.5% ～ 1% のサンプル レートを使用するのが一般的です。
StatsD は、幅広いクライアント側のサポートを備えています。
Carbon アグリゲータが必要なものをすべて提供する場合、それを使用しない理由はありません。これには 2 つの基本的な集計関数 (合計と平均) があり、実際、これらは StatsD ではカバーされていません。(歴史については定かではありませんが、Carbon アグリゲーターが既に存在し、StatsD の作成者が機能を複製することを望まなかったのではないでしょうか?) UDP を介したデータの受信も Carbon でサポートされているため、見逃してしまうのはサンプリングだけです。 、平均して集計すれば問題ありません。
StatsD は、追加の集計値を追加することで、さまざまなメトリック タイプをサポートします (たとえば、タイマーの場合: 平均、下位、上位、上位 X パーセンタイルなど)。私はそれらが好きですが、それらが必要ない場合は、Carbon アグリゲーターも良い方法です.
私は Carbon アグリゲーターと StatsD (およびBucky、Python での StatsD 実装) のソース コードを見てきましたが、それらはすべて非常に単純であるため、どちらを選択してもリソースの使用やパフォーマンスについて心配する必要はありません。
グラファイトの解像度は最小であるため、定義された間隔で同じメトリックに対して2つの異なる値を保存することはできません。StatsDは、これらを事前に集計することでこの問題を解決し、「1人のユーザーが今登録しました」と「1人のユーザーが今登録しました」と言う代わりに「2人のユーザーが登録しました」と言います。
もう1つの理由は、パフォーマンスです。