metrics入门：API性能监控

**1、常识**

Metrics，我们听到的太多了，熟悉大数据系统的不可能没听说过metrics，当我们需要为某个系统某个服务做监控、做统计，就需要用到Metrics。

举个例子，一个图片压缩服务：

1. 每秒钟的请求数是多少（TPS）？
2. 平均每个请求处理的时间？
3. 请求处理的最长耗时？
4. 等待处理的请求队列长度？

又或者一个缓存服务：

1. 缓存的命中率？
2. 平均查询缓存的时间？

基本上每一个服务、应用都需要做一个监控系统，这需要尽量以少量的代码，实现统计某类数据的功能。

以 Java 为例，目前最为流行的 metrics 库是来自 Coda Hale 的 dropwizard/metrics，该库被广泛地应用于各个知名的开源项目中。例如 Hadoop，Kafka，Spark，JStorm 中。

本文就结合范例来主要介绍下 dropwizard/metrics 的概念和用法。

Maven 配置

我们需要在pom.xml中依赖 metrics-core 包：

<dependencies> <dependency> <groupId>io.dropwizard.metricsgroupId> <artifactId>metrics-coreartifactId> <version>${metrics.version}version> dependency> dependencies>

Metric Registries

MetricRegistry类是Metrics的核心，它是存放应用中所有metrics的容器。也是我们使用 Metrics 库的起点。

MetricRegistry registry = new MetricRegistry();

每一个 metric 都有它独一无二的名字，Metrics 中使用句点名字，如 com.example.Queue.size。当你在 com.example.Queue 下有两个 metric 实例，可以指定地更具体：com.example.Queue.requests.size 和 com.example.Queue.response.size 。使用MetricRegistry类，可以非常方便地生成名字。

MetricRegistry.name(Queue.class, "requests", "size") MetricRegistry.name(Queue.class, "responses", "size")

Metrics 数据展示

Metircs 提供了 Report 接口，用于展示 metrics 获取到的统计数据。metrics-core中主要实现了四种 reporter：JMX, console, SLF4J, 和 CSV。 在本文的例子中，我们使用 ConsoleReporter 。

五种 Metrics 类型

Gauges 

最简单的度量指标，只有一个简单的返回值，或者叫瞬时状态，例如，我们想衡量一个待处理队列中任务的个数，代码如下：

public class GaugeTest { public static Queue q = new LinkedList(); public static void main(String[] args) throws InterruptedException { MetricRegistry registry = new MetricRegistry(); ConsoleReporter reporter = ConsoleReporter.forRegistry(registry).build(); reporter.start(1, TimeUnit.SECONDS); registry.register(MetricRegistry.name(GaugeTest.class, "queue", "size"), new Gauge() { public Integer getValue() { return q.size(); } }); while(true){ Thread.sleep(1000); q.add("Job-xxx"); } } }

运行之后的结果如下：

-- Gauges ------------------------------------------------ com.alibaba.wuchong.metrics.GaugeTest.queue.size value = 6

其中第7行和第8行添加了ConsoleReporter，可以每秒钟将度量指标打印在屏幕上，理解起来会更清楚。

但是对于大多数队列数据结构，我们并不想简单地返回queue.size()，因为java.util和java.util.concurrent中实现的#size()方法很多都是 O(n) 的复杂度，这会影响 Gauge 的性能。

Counters

Counter 就是计数器，Counter 只是用 Gauge 封装了 AtomicLong 。我们可以使用如下的方法，使得获得队列大小更加高效。

public class CounterTest { public static Queue q = new LinkedBlockingQueue(); public static Counter pendingJobs; public static Random random = new Random(); public static void addJob(String job) { pendingJobs.inc(); q.offer(job); } public static String takeJob() { pendingJobs.dec(); return q.poll(); } public static void main(String[] args) throws InterruptedException { MetricRegistry registry = new MetricRegistry(); ConsoleReporter reporter = ConsoleReporter.forRegistry(registry).build(); reporter.start(1, TimeUnit.SECONDS); pendingJobs = registry.counter(MetricRegistry.name(Queue.class,"pending-jobs","size")); int num = 1; while(true){ Thread.sleep(200); if (random.nextDouble() > 0.7){ String job = takeJob(); System.out.println("take job : "+job); }else{ String job = "Job-"+num; addJob(job); System.out.println("add job : "+job); } num++; } } }

运行之后的结果大致如下：

add job : Job-15 add job : Job-16 take job : Job-8 take job : Job-10 add job : Job-19 15-8-1 16:11:31 ============================================ -- Counters ---------------------------------------------- java.util.Queue.pending-jobs.size count = 5

Meters

Meter度量一系列事件发生的速率(rate)，例如TPS。Meters会统计最近1分钟，5分钟，15分钟，还有全部时间的速率。

public class MeterTest { public static Random random = new Random(); public static void request(Meter meter){ System.out.println("request"); meter.mark(); } public static void request(Meter meter, int n){ while(n > 0){ request(meter); n--; } } public static void main(String[] args) throws InterruptedException { MetricRegistry registry = new MetricRegistry(); ConsoleReporter reporter = ConsoleReporter.forRegistry(registry).build(); reporter.start(1, TimeUnit.SECONDS); Meter meterTps = registry.meter(MetricRegistry.name(MeterTest.class,"request","tps")); while(true){ request(meterTps,random.nextInt(5)); Thread.sleep(1000); } } }

运行结果大致如下：

request 15-8-1 16:23:25 ============================================ -- Meters ------------------------------------------------ com.alibaba.wuchong.metrics.MeterTest.request.tps count = 134 mean rate = 2.13 events/second 1-minute rate = 2.52 events/second 5-minute rate = 3.16 events/second 15-minute rate = 3.32 events/second

注：非常像 Unix 系统中 uptime 和 top 中的 load。

Histograms

Histogram统计数据的分布情况。比如最小值，最大值，中间值，还有中位数，75百分位, 90百分位, 95百分位, 98百分位, 99百分位, 和 99.9百分位的值(percentiles)。

比如request的大小的分布：

public class HistogramTest { public static Random random = new Random(); public static void main(String[] args) throws InterruptedException { MetricRegistry registry = new MetricRegistry(); ConsoleReporter reporter = ConsoleReporter.forRegistry(registry).build(); reporter.start(1, TimeUnit.SECONDS); Histogram histogram = new Histogram(new ExponentiallyDecayingReservoir()); registry.register(MetricRegistry.name(HistogramTest.class, "request", "histogram"), histogram); while(true){ Thread.sleep(1000); histogram.update(random.nextInt(100000)); } } }

运行之后结果大致如下：

-- Histograms -------------------------------------------- java.util.Queue.queue.histogram count = 56 min = 1122 max = 99650 mean = 48735.12 stddev = 28609.02 median = 49493.00 75% <= 72323.00 95% <= 90773.00 98% <= 94011.00 99% <= 99650.00 99.9% <= 99650.00

Timers

Timer其实是 Histogram 和 Meter 的结合， histogram 某部分代码/调用的耗时， meter统计TPS。

public class TimerTest { public static Random random = new Random(); public static void main(String[] args) throws InterruptedException { MetricRegistry registry = new MetricRegistry(); ConsoleReporter reporter = ConsoleReporter.forRegistry(registry).build(); reporter.start(1, TimeUnit.SECONDS); Timer timer = registry.timer(MetricRegistry.name(TimerTest.class,"get-latency")); Timer.Context ctx; while(true){ ctx = timer.time(); Thread.sleep(random.nextInt(1000)); ctx.stop(); } } }

运行之后结果如下：

-- Timers ------------------------------------------------ com.alibaba.wuchong.metrics.TimerTest.get-latency count = 38 mean rate = 1.90 calls/second 1-minute rate = 1.66 calls/second 5-minute rate = 1.61 calls/second 15-minute rate = 1.60 calls/second min = 13.90 milliseconds max = 988.71 milliseconds mean = 519.21 milliseconds stddev = 286.23 milliseconds median = 553.84 milliseconds 75% <= 763.64 milliseconds 95% <= 943.27 milliseconds 98% <= 988.71 milliseconds 99% <= 988.71 milliseconds 99.9% <= 988.71 milliseconds

其他

初次之外，Metrics还提供了 HealthCheck 用来检测某个某个系统是否健康，例如数据库连接是否正常。还有Metrics Annotation，可以很方便地实现统计某个方法，某个值的数据。感兴趣的可以点进链接看看。

使用经验总结

一般情况下，当我们需要统计某个函数被调用的频率（TPS），会使用Meters。当我们需要统计某个函数的执行耗时时，会使用Histograms。当我们既要统计TPS又要统计耗时时，我们会使用Timers。

**2、使用**

metric中文意思是指标，是监控系统中的基本单元，一条metric相当于db表里的一条记录，因为现在大部分metric最终也都是存在某一种db中，所以也只是换了个名字。

一张表有很多字段(column)，对应metric中有很多标签(label/tag)。

举个栗子，

1. 我们想存下cpu各个时刻load的信息，例如:

2017-12-11 17:00:00时刻cpu.load的值，用mertic表述就是metric(name=cpu.load, timestamp=1512982800, value=0.2)

2017-12-11 17:00:01时刻cpu.load的值，用mertic表述就是metric(name=cpu.load, timestamp=1512982801, value=0.1)

如果把这个metric存入db中，只要id，name，value，timestamp就够了

id	name	value	timestamp
1	cpu.load	0.2	1512982800
2	cpu.load	0.1	1512982801

2. 某一时刻，突然cpu.load飚到了50，我们想知道是哪一台服务器的load这么高，上表记录的数据就不够了, 那我们就要加一个服务器的标识：

2017-12-11 17:00:00时刻cpu.load的值，用mertic表述就是metric(name=cpu.load, timestamp=1512982800, value=0.1, instance=172.14.200.10)

2017-12-11 17:00:01时刻cpu.load的值，用mertic表述就是metric(name=cpu.load, timestamp=1512982800, value=0.1, instance=172.14.200.11)

2017-12-11 17:00:00时刻cpu.load的值，用mertic表述就是metric(name=cpu.load, timestamp=1512982801, value=0.05, instance=172.14.200.10)

2017-12-11 17:00:01时刻cpu.load的值，用mertic表述就是metric(name=cpu.load, timestamp=1512982801, value=0.05, instance=172.14.200.11)

id	name	value	instance	timestamp
1	cpu.load	0.1	172.14.200.10	1512982800
2	cpu.load	0.1	172.14.200.11	1512982800
3	cpu.load	0.05	172.14.200.10	1512982801
4	cpu.load	0.05	172.14.200.11	1512982801

我们新增了一个instance字段来记录服务器ip，用于定位是哪台服务器，俩台机器 * 俩个时刻 = 4个metric。

3. 既然有了服务器信息，那么顺便把服务器上跑的服务名也加上方便排查吧，那我们又要新增一个服务名字段service

2017-12-11 17:00:00时刻cpu.load的值，用mertic表述就是metric(name=cpu.load, timestamp=1512982800, value=0.2, instance=172.14.200.10，service=print)

2017-12-11 17:00:01时刻cpu.load的值，用mertic表述就是metric(name=cpu.load, timestamp=1512982800, value=0.1, instance=172.14.200.11，service=search)

2017-12-11 17:00:00时刻cpu.load的值，用mertic表述就是metric(name=cpu.load, timestamp=1512982801, value=0.2, instance=172.14.200.10，service=print)

2017-12-11 17:00:01时刻cpu.load的值，用mertic表述就是metric(name=cpu.load, timestamp=1512982801, value=0.1, instance=172.14.200.11，service=search)

id	name	value	instance	service	timestamp
1	cpu.load	0.1	172.14.200.10	print	1512982800
2	cpu.load	0.1	172.14.200.11	search	1512982800
3	cpu.load	0.05	172.14.200.10	print	1512982801
4	cpu.load	0.05	172.14.200.11	search	1512982801

4. 不难发现，当指标确定后，name和value不易变化，大多数改变是在对metric添加一些额外的信息（intance、service），所以干脆把额外的属性都存成json类型，那么就可以随意填写属性条数，同一个metric下每一条记录的tag也不需要相同，我们把这个json体存到tag(或label)字段。

2017-12-11 17:00:00时刻cpu.load的值，用mertic表述就是metric(name=cpu.load, timestamp=1512982800, value=0.2,tag{instance=172.14.200.10，service=print})

2017-12-11 17:00:01时刻cpu.load的值，用mertic表述就是metric(name=cpu.load, timestamp=1512982801, value=0.1,tag{instance=172.14.200.11，service=search})

id	name	value	tag	timestamp
1	cpu.load	0.1	{instance：172.14.200.10，service：print}	1512982800
2	cpu.load	0.1	{instance：172.14.200.11，service:search}	1512982800
3	cpu.load	0.05	{instance：172.14.200.10，service：print}	1512982801
4	cpu.load	0.05	{instance：172.14.200.11，service:search}	1512982801

最终我们得到了通用的metric结构，name，tag{}，value，timestamp（记住这个结构。记住这个结构。记住这个结构。），通过tag支持灵活的扩展字段。

解决了存储问题，那么要如何查询？

对于存储在DB里的metric，使用的就是SQL语法，也有些监控有用自定义的DSL，但查询思想大同小异。

例如：

想了解2017-12-11 17:00:00 - 2017-12-11 17:10:00的172.14.200.11这台服务器的总load情况，select name,sum(value) from metric where name = ‘cpu.load’ where timestamp between 1512982800 and 1512983400 group by tag.instance;

想了解2017-12-11 17:00:00 - 2017-12-11 17:10:00的print这个服务的总最大load情况，select name,max(value) from metric where name = ‘cpu.load’ and tag.service = ‘print’ where timestamp between 1512982800 and 1512983400 group by tag.service;

当然，查询的时候不聚合（group by ）也可以，但是得到的结果太过分散。