Java または Scala コードで CodaHale Metrics をクラスター化された環境で使用する場合、Graphite にレポートする際の落とし穴は何ですか?
アプリケーションの複数のインスタンスを実行してさまざまなメトリックを作成している場合、Graphite は対応できますか? つまり、レポートは累積的ですか?
たとえば、AppInstance A と B があるとします。B に 1.2 を報告するゲージと 1.3 を報告する別のゲージがある場合、Graphite での結果はどうなるでしょうか? 平均になるのでしょうか？または、一方が他方をオーバーライドします。
カウンターは累積されますか?
タイマーは累積的ですか?
それとも、各インスタンスに何らかのタグを付けて、異なる JVM インスタンスを区別する必要がありますか?
これを処理する最も簡単な方法は、インスタンスごとのメトリックを使用することです。このようにして、各インスタンスが独立してどのように動作しているかを確認できます。クラスターの全体像が必要な場合は、メトリック名にワイルドカードを使用して、一連のメトリックのsumSeriesを簡単に確認することもできます。
このアプローチの注意点は、グラファイト インスタンスでより多くのメトリックを追跡することです。そのため、ホストされたソリューションを使用している場合、コストが高くなります。
同時に入力されるとわかっているすべてのメトリックのセットに「カウント」フィールドを追加しました。次に、カウントを含むすべての値を「合計」として集計しました。これにより、セット内のすべてのメトリックの平均、合計、およびカウントの両方を見つけることができました。(はい、グラファイトのデフォルトは、一定期間の最新のサンプルを取得することです。カーボン アグリゲーター フロント エンドを使用する必要があります。)
メトリクス名に IP アドレスを追加すると、さまざまなサーバーの相対速度を計算できます。それらがすべて同じタイプで、一部が他のものより 4 倍高速である場合、問題があります。（私はこれを見ました）。前述のように、IP のような一時的な値を追加すると、デッド メトリックの問題が発生します。履歴に関心がある場合は、「古い」ための特別な IP を作成し、そこでデッド メトリックを収集してから、デッド エントリを削除できます。実際、任意のタイマー期間でのマシンの数は、非常に有用なメトリックです。