Prometheus HistogramをJavaクライアントから正しく使用して、待ち時間ではなくサイズを追跡する方法はありますか？

Question

コレクションを処理するAPIがあります。 このAPIの実行時間は、コレクションのサイズに関連しています（コレクションが大きければ大きいほど、それだけ多くの時間がかかります）。私はプロメテウスでこれを行うが、私は正しく物事をやっているかどうかわからないよできる方法を研究してい

は（ドキュメントは、この地域に欠けているビットです）。

私がした最初の事はAPIの実行時間を計測するメトリックの概要を定義しています。私はhereのように正式レート（合計）/レート（カウント）を使用しています。

ここで、入力のサイズによってレイテンシが影響を受けることがわかっているので、平均実行時間にサイズをオーバーレイしたいと考えています。私はそれぞれの可能なサイズを測定したくないので、私はヒストグラムを使うと思った。これと同じように：

Histogram histogram = Histogram.build().buckets(10, 30, 50) 
     .name("BULK_REQUEST_SIZE") 
     .help("histogram of bulk sizes to correlate with duration") 
     .labelNames("method", "entity") 
     .register(); 

注：用語「サイズ」ないは、バイト単位のサイズではなく、処理する必要のあるコレクションの長に関係しません。 2つの項目、5つの項目、50の項目...

と実行に私は（簡体字）ん

：

@PUT 
void process(Collection<Entity> entitiesToProcess, string entityName){ 
    Timer t = summary.labels("PUT_BULK", entityName).startTimer() 

     // process... 

    t.observeDuration(); 
    histogram.labels("PUT_BULK", entityName).observe(entitiesToProcess.size()) 
} 

質問：

• その後、私はGrafanaでBULK_REQUEST_SIZE_bucketで探していますすべてのバケツが同じ価値を持っていることが分かります。明らかに私は間違ったことをしています。
• もっと標準的な方法がありますか？

Answer 1

コードは正しいです（ただし、bulk_request_size_bytesはメトリック名が適しています）。

10、30および50バイトが最も要求のサイズのためにかなり小さいような問題は、あなたが次善のバケツをした可能性が高いです。より典型的な値をカバーするより大きなバケットサイズを試してみたいと思います。