メトリクス名にビルド番号を含むメトリクスを保存しています。これは、グラファイトでのメトリックの形式です。
latency.<host>.<request>.<buildNumber>.average
上記の形式の問題は、buildNumber の値が常に変化していることです。この場合、リリース サイクルのために毎週変化します。これにより、毎週新しいストレージ ファイル (.wsp) が生成されます。Whisper は事前にスペースを割り当てるため、ビルド番号が変更されたため、スペースを完全に利用することはできませんでした。
ディスク容量が安価なリソースであることは知っていますが、それでもまだ、未使用の容量がたくさんあると思います。
たとえば、各メトリクス ファイルが 10MB の大きさで、遅延のために 5000 の異なるメトリクスを送信している場合、特定のビルド番号に対して 50GB を使い果たします。毎週新しいビルド番号を送信すると、1 TB のディスク容量が 20 週間でいっぱいになり、およそ 5 か月になります。(1 TB = 1000 GB)/(1 週間あたり 50 GB) = 20 週間
上記の問題は、先月の 1 つで複数のメトリックを集計できれば解決できます。集計方法を使用して複数のメトリックを 1 つにマージする保持ポリシーを指定する方法はありますか?
あるいは、グラファイトでこの種の問題に取り組む方法はありますか?