Metrics library

1.Yammer Codehale评测

1.1 简介

堂堂Java界，只有一个Yammer Codehale作为metrics库，其余就是不成熟的Netfilx Servo，以及JavaSimon, JaMon, Perf4j这些单调的更接近的Profiler。

Codehale有几种Metrics类型：

• Counter，最单纯的Couter。
• Meter，Counter的基础上还带有Rate，包括从系统启动到现在的平均rate，1分钟，5分钟，15分钟的平均rate，15分钟这种移动rate并不是真的保存15分钟然后求平均值，而是在每隔很一小段时间，按照某个公式(使用Linux里Top的算法)对counter变化进行计算推导出1/5/15分钟的值。
• Histogram，适合于计算请求的执行时间，每次塞进去一个当前的执行时间，算出一堆数值的最小，最大，平均，方差，以及50%，75%, 90%, 95%, 98%, 99%, and 99.9% 都会小于某个值。有几种算法决定存储多少的基本数据 ，比如 SlidingWindowReservoir(固定大小)，SlidingTimeWindowReservoir(固定时间长度)，UniformReservoir(随机采样)
• Timer，等于Meter+Hitogram，既算TPS，也算执行时间。

向后报告的方式包括定期报告的如graphite, console, slf4j log，也有即时报告的如JMX(不建议用于生产环境)。各个reporter间独立Scheduler。

1.2 缺点

1. 很多数据并不是我们想要的，白白计算白白浪费性能，比如meter里的所有数值，我们更常用的还是某一个长度可选的最近一段时间内的TPS。 又比如HIsogram，方差对一般人来说不敏感，50%，75%, 90%, 95%, 98%, 99%, and 99.9% 也是太多了，最好可以自行配置需要的数值。
2. Reporter不能同时使用，ConsoleReporter计算一次值，GraphiteReporter再计算一次值。
3. Meter经常计算推导的1/5/15分钟值有点浪费，影响traffic。

2. SpringSide改造

结合Statsd的做法，在Yammer Codahale Metircs的基础上重写:

• Reporter机制，所有Reporter可共用一个Scheduler，触发时计算一次metrics值的Snapshot，然后在各个reporter间共享。暂时没有了JMXReporter。
• Counter和Meter合一，Meter不再提供原来的所有rate值，只提供上一次report到现在的rate。
• Histogram，去除了方差，而50%，75%, 90%, 95%, 98%, 99%, and 99.9%变成可配置多个任意值。基本数据只存储上一次report到现在的数据。以后还可能支持设置采样算法，以及最大存储量限制。
• Graphite，改变原来每条记录flush()一次，学习Collectd的Graphite Reporter，成为尽量buffer到足够大再flush()。以后可能增加健壮性，比如如果Graphite失效时本地临时缓存。