web-dev-qa-db-ja.com

DropWizardメトリクスメーターとタイマー

私は DropWizard Metricsライブラリ （以前のCoda Haleメトリックス）を学んでおり、Meters vs Timersをいつ使用すべきかについて混乱しています。ドキュメントによると：

メーター：メーターは、一連のイベントが発生する割合を測定します

そして：

タイマー：タイマーは基本的に、イベントのタイプの期間のヒストグラムとその発生率のメーターです

これらの定義に基づいて、これらの違いを見分けることはできません。私を混乱させているのは、Timerが使用されると思っていた方法で使用されていないことです。私にとって、Timerはまさにそれです。タイマーです。 start()とstop()の間の時間差を測定する必要があります。しかし、Timersはイベントが発生するレートもキャプチャするようで、Metersつま先を踏んでいるように感じます。

各コンポーネントが出力するものの例を見ることができれば、これらのどちらをいつ/どこで使用するかを理解するのに役立ちます。

javatimerdropwizardmetricscodahale-metrics
62
smeeb

DWメトリクスタイマー[〜＃〜] [〜＃〜]、特にDWメトリクスメーターであるため、部分的に混乱しています。

メーターは、Hz（イベント/秒）で測定されるレートにのみ関係します。各メーターの結果、4（？）個の異なるメトリックが公開されます。

  • メトリックスが開始されてからの平均（平均）レート
  • 1、5、および15分のローリング平均レート

コードのさまざまなポイントで値を記録することでメーターを使用します-DW Metricsは、各コールのウォール時間を指定した値とともに自動的に書き留め、これらを使用してその値が増加する割合を計算します：

Meter getRequests = registry.meter("some-operation.operations")
getRequests.mark() //resets the value, e.g. sets it to 0
int numberOfOps = doSomeNumberOfOperations() //takes 10 seconds, returns 333
getRequests.mark(numberOfOps) //sets the value to number of ops.

333の操作が発生し、mark（）の2つの呼び出し間の時間が10秒であったため、レートは33.3 Hzになると予想されます。

タイマーは、これらの4つのメトリックを計算し（各Timer.Contextを1つのイベントと見なします）、それらにいくつかの追加メトリックを追加します。

  • イベント数のカウント
  • メトリックの開始以降に見られる最小、平均、および最大の期間
  • 標準偏差
  • 50、97、98、99、および99.95パーセンタイルで分布した期間を記録する「ヒストグラム」

タイマーごとに合計15のメトリックが報告されます。

要するに：タイマーは多くのメトリックを報告し、理解するのが難しい場合がありますが、一度実行すると、スパイクの動作を見つける非常に強力な方法になります。

事実、2つのポイント間で費やされた時間を収集するだけでは、それほど有用なメトリックではありません。考慮してください：あなたはこのようなコードのブロックを持っています：

Timer timer = registry.timer("costly-operation.service-time")
Timer.Context context = timer.time()
costlyOperation() //service time 10 ms
context.stop()

CostlyOperation（）が一定のコスト、一定の負荷を持ち、単一のスレッドで動作すると仮定しましょう。 1分間のレポート期間内に、この操作の時間を6000回と予想する必要があります。明らかに、ワイヤー6000xを介して実際のサービス時間をレポートするのではなく、代わりに、目的のレポートウィンドウに合うようにこれらのすべての操作を要約する何らかの方法が必要です。 DW Metricsのタイマーは、1分に1回（レポート期間）自動的にこれを行います。 5分後、メトリックレジストリは次を報告します。

  • レート100（イベント/秒）
  • 100の1分間の平均レート
  • 100の5分間の平均レート
  • 30000のカウント（合計イベント数）
  • 最大10（ミリ秒）
  • 10分
  • 10の平均
  • 10の50パーセンタイル（p50）値
  • 10の99.9パーセンタイル（p999）値

ここで、操作が時々Railsから完全に外れ、長期間ブロックされる期間に入ることを考えてみましょう。

Timer timer = registry.timer("costly-operation.service-time")
Timer.Context context = timer.time()
costlyOperation() //takes 10 ms usually, but once every 1000 times spikes to 1000 ms
context.stop()

1分間の収集期間では、1000回の実行ごとに時間がかかるため、6000回未満の実行になります。約5505まで動作します。この最初の1分（合計システム時間6分）後、次のように表示されます。

  • 平均レート98（1秒あたりのイベント数）
  • 91.75の1分間の平均レート
  • 98.35の5分間の平均レート
  • 35505のカウント（合計イベント数）
  • 最大1000時間（ミリ秒）
  • 10の最小期間
  • 10.13の平均期間
  • 10の50パーセンタイル（p50）値
  • 1000の99.9パーセンタイル（p999）値

これをグラフ化すると、ほとんどのリクエスト（p50、p75、p99など）は10ミリ秒で完了しましたが、1000（p99）のうち1つのリクエストが1秒で完了しました。これは、平均レートのわずかな減少（約2％）および1分平均のかなりの減少（約9％）とも見なされます。

一定期間の平均（レートまたは期間）だけを見ると、これらのスパイクを見つけることはできません-多くの成功した操作で平均すると、それらはバックグラウンドノイズに引きずり込まれます。同様に、最大値を知っているだけでは、最大値が発生する頻度がわからないため、役に立ちません。これが、ヒストグラムがパフォーマンスを追跡するための強力なツールであり、DW Metricsのタイマーがレートとヒストグラムの両方を公開する理由です。

135
Matthew Mark Miller