MicroProfile Metrics・服務沒人用?!
就跟各行各業的人一樣,只需要一點點鼓勵、一些些成就感,研發人就能繼續堅持走下去。然而,更習慣或者說必須時時面對著機器的我們,曝光在人群面前的機會相對較少,自然,這些小小卻大大的溫暖就很難出現在日常之中。所以,在孤單的研發路上,自我鼓勵(催眠
真的是個非常重要的技能!
對於開發服務的系統(後端)工程師來說,程式碼寫得好不好確實是個成就感來源,但就算程式碼寫得再好,系統架構設計得再怎麼穩固有彈性,如果沒人使用,真的也只能孤芳自賞、故作堅強。(இдஇ; )
有沒有人使用這事,又因為工作範圍不同,而希望可以得知不同數值。負責寫登入系統的會想要知道同時在線人數、瞬間最高在線人數,如果這些數字很高,真是太完美了!(爽~
;負責寫服務本身的會想要知道被呼叫了幾次、運作效率、是不是常常被呼叫,如果這些數字該高的高、該低的低,真的是走路也有風!(超爽 dre~研發人怎麼感覺蠻好取悅的 XD
如果你和我一樣,需要一點點自我鼓勵的動力,MicroProfile Metrics(後簡稱 MPMetircs)就是一個可以用來 自我感覺良好 咳咳!我的意思是提供科學監測、提供精確數字的工具!
不意外的,MPMetrics 一如既往的貼心,針對多數需求提供了 @annotaion
來讓 監測 變得簡單,有特殊情況也可以用寫程式呼叫框架的方法來解決!本文重點會放在多數需求的解決上,建議大家若有閒暇,能多多閱讀規格書,相信一定會有不少的收穫!
存取監測資料 REST API
MPMetrics 隨著 PayaraMicro 啟動而自動啟動,可以透過以下三個級別的端點存取:
/metrics
=> 所有的監測資料匯總/metrics/{scope}
=> 指定 scope 的監測資料匯總,scope 共有三種:base
=> MicroProfile 要求實作者須提供的監測資料,與 Java 運作環境相關vendor
=> 實作者額外提供的監測資料application
=> 應用開發者定義之監測指標的匯總資料
/metrics/{scope}/{metric_name}
=> 某個 scope 下指定指標的監測資料
簡單說對開發者而言,基本上只要監測 /metrics/application
就可以了!但若有更近一步的需求,譬如自己想寫 UI 來呈現某個監測指標的數據,則可以呼叫 /metrics/application/我的指標
。
MPMetrics 支援兩種檢測資料的格式,一種是 JSON,另一種則是 OpenMetrics。預設情況下,取回的會是 OpenMetrics 的格式,也就是如果用瀏覽器存取,就會是這種格式,如:以下為存取 /metrics/vendor
取回的結果。
# TYPE vendor_system_cpu_load gauge
# HELP vendor_system_cpu_load Display the "recent cpu usage" for the whole system. This value is a double in the [0.0,1.0] interval. A value of 0.0 means that all CPUs were idle during the recent period of time observed, while a value of 1.0 means that all CPUs were actively running 100% of the time during the recent period being observed. All values betweens 0.0 and 1.0 are possible depending of the activities going on in the system. If the system recent cpu usage is not available, the method returns a negative value.
vendor_system_cpu_load 0.15451174289245984
如果要取回 JSON 格式,就必須使用工具,將請求的回傳格式設定成 application/json
,如:執行 curl -H"Accept: application/json" localhost:8080/metrics/vendor
將取回以下資料(為了閱讀手動調整了格式):
{
"system.cpu.load": 0.10121457489878542
}
監測好簡單!
MPMetrics 最方便的地方就在於提供了一系列直接可用的 @annotation
,只要在 method
上標註,不用任何邏輯異動,就達成了監測的目的。以下,就是那些好用的工具!
Annotation | 說明 |
---|---|
@Counted | 計數監測。統計被呼叫了幾次。 |
@Gauge | 測量指標。開發者自訂的任何數值。 |
@ConcurrentGauge | 並行呼叫的複合型監測。包括:
|
@Metered | 以測量次數為基礎的複合型監測。包括:
|
@Timed | 以測量時間為基礎的複合型監測。包括:
|
接著,就實際來使用吧!
// Java Code
@Path("hello")
@ApplicationScoped
public class HelloMPMetrics {
private int size;
@Counted(name = "COUNT")
@Timed(name = "TIME")
@Metered(name = "METER")
@ConcurrentGauge(name = "CONCURRENT")
@GET
public String sayHello() {
return "Hello World - " + ++size;
}
@Gauge(name = "GAUGE", unit = MetricUnits.NONE)
@Path("size")
@GET
public int getSize() {
return size;
}
}
// The Metrics
{
"io.qstudio.practice.mpmetrics.HelloMPMetrics.METER": {
"count": 1,
"fiveMinRate": 0.1934432200964012,
"oneMinRate": 0.16929634497812282,
"fifteenMinRate": 0.19779007785878447,
"meanRate": 0.0610862955162311
},
"io.qstudio.practice.mpmetrics.HelloMPMetrics.COUNT": 1,
"io.qstudio.practice.mpmetrics.HelloMPMetrics.TIME": {
"fiveMinRate": 0.1934432200964012,
"max": 823999,
"count": 1,
"p50": 823999,
"p95": 823999,
"p98": 823999,
"p75": 823999,
"p99": 823999,
"min": 823999,
"fifteenMinRate": 0.19779007785878447,
"meanRate": 0.06112485269961083,
"mean": 823999,
"p999": 823999,
"oneMinRate": 0.16929634497812282,
"stddev": 0
},
"io.qstudio.practice.mpmetrics.HelloMPMetrics.GAUGE": 1,
"io.qstudio.practice.mpmetrics.HelloMPMetrics.CONCURRENT": {
"current": 0,
"min": 0,
"max": 0
}
}
使用起來就是這麼簡單!數據的記錄與統計運算,MPMetrics 全包了!
只要在想要監測的 method
上標註上要使用的監測方法,監測結果就會自動的產生。
在此特別將學習過程中幾個要點整理出來:
- 因為是透過
CDI
進行管理,所以當該方法還沒有被呼叫過,也就是還未受管理的情況下,報告是不會有內容的 - 有計數效果的
@annotation
,只有外部的呼叫會被統計
class
內的method
互相呼叫,不會對監測數據造成任何影響- 包括:
@Counted
、@ConcurrentGauge
、@Metered
以及@Timed
- 監測指標的名稱要妥善管理,設定的方式請參考規格書跟 API 文件
- 名稱是可以重複的
- 同一名稱可以透過添加標籤來進行區別
文末,做個簡單的結語,
MPMetrics 提供了一個完全不會影響到應用邏輯的極簡方法,讓開發者對程式及服務進行監測,亦提供便於查詢的 REST API 供開發者獲取監測資料。不僅免去了資料的收集與複雜統計,還可用科學方法來評估自己的服務,該用就用吧~大家!
by Arren Ping