metrics

对于分布式软件系统来说Metrics已经成为了不可缺少的组成部分，通过它我们可以了解系统的运行状况、健康状况、性能状况，通过对历史数据的分析，也可以帮助我们发现系统缺陷以及避免系统不稳定的发生。比如通过JVM数据我们可以优化系统GC策略，通过TPS和latency数据可以获知系统的压力和性能表现。

Hadoop作为目前流行的分布式计算系统，提供了一套简单有效的metrics框架。接下来通过对这个框架的分析和学习，可以帮助我们在软件中构建自己的metrics体系。

Hadoop支持的metrics方式
hadoop支持两种metrics方式，其中一种是JMX方式。通过将系统内建立的多个metrics 数据转化为dynamic mbeans注册到JVM的JMX Mbean服务器中，就可以利用JMX框架来获取以及发布这些数据。对于我们客户端来说可以使用JConsole来连接指定的JMX服务器。

从客户端%java_home%/bin下面启动jconsole

服务器metrics数据监控界面

从上图可以看出利用JMX方式监控与展示数据非常方便，但是受到很多的限制，用起来也不太直观，尤其是集群状况下的成百上千台服务器数据的收集、展示、计算、预警等。因此hadoop支持另外一种方式，通过一个简单的框架，实现数据的收集与发布。发布方式上我们可以选择写文件、ganglia甚至是自定义的方式来对外发布数据，后面会详细介绍这个框架的实现和我们所能做的扩展应用。

Hadoop metrics与ganglia
hadoop metrics框架只能做到本机数据的收集与发布，在集群环境下成百上千台服务器数据的收集汇总和展示还需要第三方的工具来实现。我们常用的就是ganglia，下图展示的是ganglia的系统结构。Hadoop将metrics数据发送给集群每个节点运行的gmond程序，然后gmetad周期性的轮询gmond收集到的信息，并存入rrd数据库，通过web服务器可以对其进行查询展示。

Ganglia上展示的metrics数据

基于 metrics的应用

看到这里，大家对hadoop的metrics应该有大致的了解了，他的作用就是收集、发送数据，但是这些还远远不够，数据如何存储、分析以及预警才是我们最终的目的。而这些系统加在一起才能发挥巨大的作用。后面我们会仔细介绍hadoop metrics框架，通过它来构建我们自己的metrics体系。

我们如何才能获知一个软件系统的运行状况？如何才能将软件的运行数据暴露给用户查看？通过Hadoop的metrics框架就能做到这一点。它可以帮助我们计算数据，收集数据，发送数据，这一切仅需要我们建立几个数据类和调用几个接口。

Hadoop metrics的总体框架

MetricsContext

通过ContextFactory我们可以获得一个MetricsContext对象，它保存这一组metrics的上下文信息，每个context都可以启动一个monitor线程来按一定周期来收集和发送这些数据。前面我们也提到了hadoop可以提供写文件，发送ganglia等方式来发送metrics，就是通过继承AbstractMetricsContext产生不同的Context的类来实现的。具体要采用那种方式来发送数据可以通过配置文件来确定，后面会加以介绍。

Updater

Updater是数据收集的主体，这个接口最重要的是doUpdates方法。将应用实现的updater类注册到MetricsContext中，context的monitor线程就会定期调用updater的doUpdates方法来抓取数据。通常在doUpdates里我们会对系统的各种metrics做初步计算处理并push到MetricsRecord中。

MetricsRecord

顾名思义它是一个时间周期下的一条数据，每个context下可以包含多个MetricsRecord。Context调用doUpdates收集到MetricsRecord后，再将它发送给文件或者ganglia。对于ganglia来说每一个监控点名称格式就是：context名称. Record名称.metrics名称。

MetricsBase

所有具体的metrics数据类都会继承MetricsBase，常用的有以下几种：
MetricsIntValue：整型数值
MetricsLongValue：长整型数值
MetricsTimeVaryingInt：一个时间周期内整型累积值，push到MetricsRecord后从0开始累积。
MetricsTimeVaryingLong：一个时间周期内长整型累积值
MetricsTimeVaryingRate：保存了操作所花费的时间和该时间内的操作次数。最终发送出去会是两个数值：一个时间周期内的总操作次数和每个操作所花费的平均时间（操作总时间/操作次数）。该metrics内部还保存了单次操作时间的min和max。

Hbase也扩展了几种metrics类型：
MetricsAvgValue：记录用户设置的值及设置的次数，最终输出的是平均值，收集完清零。
MetricsIntervalInt：一个时间周期内整型数值，收集完清零。
MetricsRate：一个时间周期内的数据/时间周期的长度，收集完清零。
MetricsString：一个字符串，主要用于JMX，ganglia不支持。

JMX支持

MetricsRegistry：注册了所有需要export到JMX的metrics
MetricsDynamicMBeanBase：将MetricsRegistry中的metrics生成JMX需要的MBeanInfo。

Hadoop metrics的配置

配置文件的名称通常为hadoop-metrics.properties，下面是一个hbase metrics的常用配置：

# Configuration of the “hbase” context for ganglia
# Pick one: Ganglia 3.0 (former) or Ganglia 3.1 (latter)
hbase.class=org.apache.hadoop.metrics.ganglia.GangliaContext31
hbase.period=15
hbase.servers= hostname:8649

其中hbase.class定义了名叫hbase的MetricsContext 实现类是GangliaContext31（在cloudera的hadoop版本中提供），每次收集数据的周期是15秒，发送数据到servers中定义的gmond地址。需要注意的是ganglia默认的收集数据周期为15秒一次，我们程序的采样周期需要与它保持一致。

通过上面的介绍，大家应该大致了解了hadoop metrics框架原理，其实并不复杂，但是很好的解决了数据收集和发送的问题。除了这个框架以外，数据的处理分析就需要我们来完成了，这个才是metrics系统的重点，下一篇文章会介绍我们的一些应用。

大型分布式系统中需要metrics来了解系统状态已成为系统必需的功能之一。其实测试系统甚至测试用例中也同样需要metrics。通过这些指标我们可以了解测试的进度、状况、以及一些过程情况，比如性能指标和一些无法用是否判断数据。下面我们就用一个简单的例子来看看如何使用Hadoop metrics。

创建Updater

Updater是一个拥有doUpdates方法的接口，将实现了这个接口的类注册到MetricsContext中，context就能周期性的调用doUpdates来收集metrics。因此实现Updater是metrics框架应用中最重要的事情。下面是一个简单的Updater：

public class ClientMetrics implements Updater {   private MetricsContext context;   private MetricsRegistry registry = new MetricsRegistry();   private MetricsRecord metricsRecord;   private long lastUpdate = System.currentTimeMillis();   // 建立一个metrics用于统计1秒内的写请求数   private final MetricsRate writeRequests = new MetricsRate("writeRequests",       registry);   public ClientMetrics() {     // 获取一个名为test-client的context，并启动context的monitor线程开始收集数据     context = MetricsUtil.getContext("test-client");     // 在context中新建一个名为metrics的record     metricsRecord = MetricsUtil.createRecord(context, "metrics");     // 将updater注册到context中     context.registerUpdater(this);   }   @Override   // context采集metrics数据   public void doUpdates(MetricsContext context) {     synchronized (this) {       // 将一个metrics 写入record       this.writeRequests.pushMetric(this.metricsRecord);     }          // 将record的数据更新到context     this.metricsRecord.update();   }   public void incrementWriteRequests(final int inc) {     this.writeRequests.inc(inc);   }   public void stop() {     if (context != null) {       // 停止一个context       metricsRecord.remove();       context.close();       context = null;     }   } }

创建配置文件

配置文件的名称通常为hadoop-metrics.properties，需要放置在classpath中：

test-client.class=org.apache.hadoop.metrics.ganglia.GangliaContext31
test-client.period=15
test-client.servers= hostname:8649

通过以上的操作，配合ganglia，metrics模块就可以运行起来了，这也是最常用的方式，但是也存在着很多不方便的地方。下面就分享下我们metrics应用的一些经验。

数据收集完成之后

Hadoop metrics框架以及Ganglia很好的完成了数据的采集和集群规模的收集工作。但是也有很多让我们不爽的地方：

1、  ganglia仅能按照1小时、1天、1周、1年来浏览数据，显然无法做进一步的分析处理。为了满足我们随意时间查询以及多重数据整合分析的需求，必须将数据从ganglia中取出来另外存储为更加灵活的数据结构。经过同事的一些实践发现最靠谱的就是文件存储。于是就有了以下流程：hadoop metrics采集–>ganglia收集汇总–>自定义程序转存为固定格式文件–>web查询分析界面及程序。这个方案充分利用了文件的快速检索和顺序读优势，而且每个指标一个文件也方便迁移和管理。

2、  如果一个集群的指标太多、实时性要求越来越高、分析要求越来越复杂，那我们就不得不放弃ganglia。通过扩展MetricsContext可以实现自己的数据发送算法，将集群数据发送到数据处理中心，通过更加有针对性的数据处理方案来分析海量指标数据。

通过上面的介绍我想大家已经掌握了metrics体系的构建思路，不一定非要使用hadoop的metrics框架我们也完全有能力创造出更适合自己的metrics解决方案。