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