metrics簡述
Metrics可以爲你的代碼的運行提供無與倫比的洞察力。作爲一款監控指標的度量類庫，它提供了很多模塊可以爲第三方庫或者應用提供輔助統計信息， 比如Jetty, Logback, Log4j, Apache HttpClient, Ehcache, JDBI, Jersey, 它還可以將度量數據發送給Ganglia、Graphite、grafana+Influxdb以提供圖形化的監控。推薦使用grafana。
Metrics提供了Gauge、Counter、Meter、Histogram、Timer等度量工具類以及Health Check功能。
<dependencies>
<dependency>
<groupId>com.codahale.metrics</groupId>
<artifactId>metrics-core</artifactId>
<version>${metrics.version}</version>
</dependency>
</dependencies>
使用示例：
https://blog.csdn.net/ruthywei/article/details/80967063
https://www.jianshu.com/p/e5bba03fd64f
https://www.jianshu.com/p/469648907036
網上介紹使用的文章有很多，這裏我就不介紹使用了，說下我認爲在業務開發過程中使用上很重要的幾個指標。pqs rt 。尤其是對於業務系統來說，大多數的場景就是 A->B->C 這種依賴調用關係，所以往往我們更關心他們的吞吐能力和RT。
下面我們就着重的說明下Metrics中Timer指標。
先看一段Timer 打出的日誌格式。
name=requests, count=171396, min=0.480973, max=4.228569, mean=1.0091534824902724,
stddev=0.3463516148968051, median=0.975965,
p75=1.1458145, p95=1.4784138999999996, p98=1.6538238999999988, p99=2.185363660000002, p999=4.22124273,
mean_rate=0.0, m1=0.0, m5=0.0, m15=0.0, rate_unit=events/millisecond, duration_unit=milliseconds
metrics 統計值。
“version”: “3.0.0”,
“timers”: {
“count”: 0,// 總次數
“max”: 0,// 最長時間
“mean”: 0,// 平均時間
“min”: 0,// 最短時間
“p50”: 0,// 中位數
“p75”: 0,// 75th 分位數
“p95”: 0,// 95th 分位數
“p98”: 0,// 98th 分位數
“p99”: 0,// 99th 分位數
“p999”: 0,// 999th 分位數
“stddev”: 0, //方差
“m15_rate”: 0,// 15分鐘 請求數/每秒的比率
“m1_rate”: 0,// 1分鐘 請求數/每秒的比率
“m5_rate”: 0,// 5分鐘 請求數/每秒的比率
“mean_rate”: 0,// 平均每秒請求數
“duration_units”: “seconds”,//該Timer的單位
“rate_units”: “calls/second”//比率單位
}
這個指標還是比較詳細的，裏面會有mean、p75、p99… 這個其實是很關鍵的數據指標，一般我們調用三方系統的時候，我們出於降級考慮，都會找業務方要他們的一個線上服務的rt結果，一般不負責任的業務方都會給你一個他們的均值RT，也就是我們上面看到的mean的值。
這種場景很常見，我們大多數的公司(不乏像BAT一些大廠)，一個部門都是這樣。但是給你的均值RT 你就真敢用嗎？用了就都能不超時嗎？超時了可用率大致多少？99？999？如果你一個系統接口,要滿足999個可用性，你用哪個平均值能滿足要求嗎？
另外一個場景就是我們壓測或是排查線上超時問題的時候，會發現你調用的服務大量超時，你反饋給業務方的時候，業務方會說我看我們的監控沒問題啊，rt 還是很低，但是你這邊就是超時嚴重，這時如果你有類似於全鏈路排查的工具，恭喜你，你會發給他一個traceId 的東西，讓他看你這個耗時是多少，但是如果你沒有，這時情況就複雜了，誰都不會認這個事，說回來，只有你這邊做好了監控，吧監控值反饋給他(拍他臉上)，尤其是在一個誰的責任說不清楚的情況下，顯得尤其重要。
下面就來說是各個指標，尤其是p99 和p999
1、最大值、最小值、平均數：容易理解，不做贅述，即例子中的min=19.090878, max=31.171142，mean=19.985073202643935，表明最小、最大和平均響應時間；
2、中位數：一個樣本、種羣或概率分佈中的一個數值，用它可以講所有數據劃分爲相等的上下兩部分。對於有限的數集，可以通過把所有觀察值高低排序後找出正中間的一個作爲中位數。如果數據總數是偶數個，通常取最中間的兩個數值的平均數作爲中位數。如示例中的median=19.858742，代表所有響應時間中最中間的那個數字，可見和平均數（mean=19.985073202643935）並不相等。
3、差異量
方差：每個樣本值與全體樣本值的平均數之差的平方值的平均數，用來度量隨機變量和其數學期望（即均值）之間的偏離程度. 數值越小，表明數據分佈越集中，例子中即爲stddev=0.3463516148968051，表明數據相對很集中。
4、分位數：分位數是將總體的全部數據按從小到大順序排列後，處於各等分位置的變量值。例如上面的p95, p999都是這種概念。例如p999=4.22124273，代表99.9%的請求響應時間不大於4.22124273ms；
p99 ; p表示：percent 百分比。
下面摘抄子英文：
Why Did We Choose to Implement This?
It is extremely useful for a lot of reasons. Averages can be misleading. Customers don’t just experience an application’s average behavior; they remember the worst experience they’ve had. P99 metrics show outlying behavior in the long-tail, while averages don’t. You can rank by highest-latency p99 in the Profiler which makes it very easy to focus on the queries with the worst outliers.They’re most meaningful for high-frequency queries; where other monitoring systems have trouble providing any visibility at all into fast and frequent queries, we can also identify outlier performance. This is a huge blind spot for many people.
It is also a useful feature for proactive monitoring and notification. Since we are generating this value per-query you can set an alert on specific query performance. This could be a much more accurate way of alerting on unusual behaviour as compared to setting a threshold against average latency.
說白了就是，平均值只能反映一般情況，而百分比指標其實是在於統計分佈圖中大多數的場景，顯示了長尾效應的異常行爲，而平均值卻沒有。即瞭解請求對應用程序的最差體驗。曾經經歷過的耗時最長的經歷。
它們對於高頻查詢的場景最具有意義。如果其他監控系統無法提供對快速和頻繁查詢的任何可見性，則我們還可以確定異常性能。對於大多數人來說，這是一個巨大的盲點。
參考：
http://www.strolling.cn/category/metrics/
英文介紹：
https://www.vividcortex.com/blog/announcement-p99-percentile-metrics