簡體   English   中英

DropWizard 指標儀表與計時器

[英]DropWizard Metrics Meters vs Timers

我正在學習DropWizard Metrics 庫(以前稱為 Coda Hale 指標),我對何時應該使用MetersTimers感到困惑。 根據文檔:

儀表:儀表測量一組事件發生的速率

和:

計時器:計時器基本上是一種事件持續時間的直方圖和其發生率的計量表

根據這些定義,我無法辨別它們之間的區別。 讓我感到困惑的是Timer沒有按照我預期的方式使用它。 對我來說, Timer就是:一個定時器; 它應該測量start()stop()之間的時間差異。 但似乎Timers也捕捉事件發生的速率,感覺就像他們踩着Meters腳趾一樣。

如果我能看到每個組件輸出的示例,這可能有助於我了解何時/何地使用其中任何一個。

您感到困惑的部分原因是 DW Metrics TimerDW Metrics Meter。

Meter 只與速率有關,以 Hz(每秒事件數)為單位。 每個 Meter 導致發布 4(?) 個不同的指標:

  • 自 Metrics 啟動以來的平均(平均)比率
  • 1、5 和 15 分鍾滾動平均費率

您可以通過在代碼中的不同點記錄一個值來使用 Meter -- 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.

我們希望我們的速率為 33.3 Hz,因為發生了 333 次操作,並且兩次調用 mark() 之間的時間為 10 秒。

Timer 計算上述 4 個指標(將每個 Timer.Context 視為一個事件),並向它們添加許多其他指標:

  • 事件數量的計數
  • 自指標開始以來看到的最小、平均和最大持續時間
  • 標准差
  • “直方圖”,記錄分布在第 50、97、98、99 和 99.95 個百分位數的持續時間

每個計時器報告了大約 15 個指標。

簡而言之:計時器報告了很多指標,它們可能很難理解,但是一旦你這樣做了,它們是一種非常有效的方法來發現尖峰行為。


事實上,僅僅收集兩點之間花費的時間並不是一個非常有用的指標。 考慮:你有一個這樣的代碼塊:

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 的計時器自動為我們執行此操作,每分鍾一次(我們的報告周期)。 5 分鍾后,我們的指標注冊表將報告:

  • 速率為 100(每秒事件數)
  • 1 分鍾的平均速率為 100
  • 5 分鍾平均速率為 100
  • 計數 30000(看到的事件總數)
  • 最多 10 (ms)
  • 10分鍾
  • 平均 10
  • 第 50 個百分位數 (p50) 值為 10
  • 第 99.9 個百分位數 (p999) 的值為 10

現在,讓我們考慮進入一個時期,偶爾我們的操作會在很長一段時間內完全脫離軌道和阻塞:

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 分鍾的收集期內,我們現在會看到不到 6000 次執行,因為每 1000 次執行需要更長的時間。 大約為 5505。在第一分鍾(系統總時間為 6 分鍾)之后,我們現在將看到:

  • 平均速率為 98(每秒事件數)
  • 1 分鍾平均匯率為 91.75
  • 98.35 的 5 分鍾平均速率
  • 計數 35505(看到的事件總數)
  • 最大持續時間為 1000 (ms)
  • 最短持續時間 10
  • 平均持續時間 10.13
  • 第 50 個百分位數 (p50) 值為 10
  • 1000 的第 99.9 個百分位數 (p999) 值

如果您繪制此圖,您會看到大多數請求(p50、p75、p99 等)在 10 毫秒內完成,但 1000 個(p99)中的一個請求在 1 秒內完成。 這也將被視為平均比率略有下降(約 2%)和 1 分鍾平均值(近 9%)的大幅下降。

如果您只查看時間平均值(速率或持續時間),您將永遠不會發現這些尖峰——當對許多成功操作進行平均時,它們會被拖入背景噪音中。 同樣,僅僅知道最大值也無濟於事,因為它不會告訴您最大值出現的頻率。 這就是直方圖是跟蹤性能的強大工具的原因,也是 DW Metrics 的計時器發布速率和直方圖的原因。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM