HBase Metrics机制、架构

HBase Metrics

HBase Metrics是一种监控信息实时收集机制。它负责收集的信息有：

• 功能性信息（Compaction Queue、Store Files个数等）
• JVM使用信息 (Heap Memory 的变化)
• rpc访问信息

借助与Hadoop Metrics同样的方式，向Ganglia汇报。

Ganglia is a scalable distributed monitoring system for high performance computing systems such as clusters and Grids.

• based on a hierarchical design targeted at federations of clusters
• relies on a multicast-based listen/announce protocol to monitor state within clusters
• uses a tree of point-to-point connections amongst representative cluster nodes to federate clusters and aggregate their state
• XML for data representation
• XDR for compact, portable data transport
• RRDtool for data storage and visualization

Ganglia的架构图：

Ganglia相关特性：

• gmond(Ganglia-monitor)负责收集本节点或者本集群内的的build-in Metrics.例如/proc下系统提供的资源使用状况。
• Application-Level的信息可以发送给gmond，也可以直接发送给gmetad。

HBase Metrics的设计架构

HBase Metrics借助HadoopMetrics的实现，默认延续了Metrics 1的配置方式。

这里以RegionServer内RegionServerMetrics为例，阐述数据收集流程。

1）RegionServerMetrics根据classpath下conf/hadoop-metrics.properties的配置，创建一个Context实例

在配置中，hbase.class指定的Context实例的实现是org.apache.hadoop.metrics.ganglia.GangliaContext31，类图的结构关系如下。

• RegionServerMetrics实现了Updater接口，实现了doUpdater(MetricsContext)的方法。
• RegionServerMetrics构造函数中，将自己注册到GangliaContext31。
• 创建MetricsRecord，加载到GangliaContext31里。
• 启动startMonitoring()过程。在AbstractMetricsContext里，是TimeTask来作为一个线程，周期性调用doUpdater().

2) HRegionServer周期性的执行doMetrics()方法。

该方法只更新在RegionServerMetrics定义的metrics对象，周期性更新的间隔是由”hbase.regionserver.msginterval”决定。

3）GangliaContext31获取Metrics的更新，然后发送给Ganglia。

该方法会将MetricsRecord发送给Ganglia的Gmond或者Gmetad。

注意：该过程的周期性间隔时间，是由conf/hadoop-metrics.properties文件的hbase.period的值来控制。

整体过程的框架图如下：

使用更加简洁的语言描述：

1）被监控的对象或者系统，实现Updater接口，注册到监控系统的Context中。

 

 

2）被监控的系统会根据自己的时间步调对需要采集的数据进行更新。

 

3）监控系统内置的TimeTask，则会根据自己的更新周期(period)，调用Updater的接口，从被监控对象获取MetricsRecord，并按照Context的接口emitRecord的方法，将数据写入文件、第三方接收端、或者不处理(NullContextWithUpdateThread)。

Metrics机制特性总结

• 降低HBase内核与Metrics模块的接口耦合性。支持多种Metrics机制的emitRecord方式。
• 降低服务内部Metrics更新步调与监控数据收集的依赖性。更新数据是内存操作，而如果Fetch操作是网络操作，而且，是由其它线程独立来处理。
• Push操作使用Non-blocking的Connectionless package delivery service(DatagramPacket)来实现。采集的信息很多，可以忽略网络的可靠性，从而使得Push操作不是瓶颈。

HBase Metrics机制配置

1、Metrics种类

2、配置的方式

第一种配置方式：

在${HBASE_HOME}/conf/hadoop-properties中，取消相关注释项。例如我们以hbase metrics为例。

hbase.class=org.apache.hadoop.metrics.ganglia.GangliaContext31   #标识了hbase metrics采用哪一个上下文来发送数据
hbase.period=500 #见上图
hbase.servers=192.168.15.224:8649

这里的hbase.servers=192.168.15.224:8649标识了一个GMond的IP：PORT.

这里请注意两点：

1）保证所有需要发送Metrics的节点的Ganglia-monitor要存在。因为如果该Daemon Crash之后，即使Hbase相关的Metrics发送到其它节点的GMond，也无法显示。

2）注意在gmetad.conf中添加需要监控的节点。

data_source “my cluster” localhost 10.1.4.104 10.1.4.105 10.1.4.106 10.1.4.107 10.1.4.108 10.1.4.109 10.1.4.110 10.1.4.111 10.1.4.112  #这里默认使用8649端口

第二种配置方式：

配置Metrics输出成文件格式。同样在${HBASE_HOME}/conf/hadoop-properties中，取消相关注释项。例如我们以jvm metrics为例。

# Configuration of the “jvm” context for file
# jvm.class=org.apache.hadoop.hbase.metrics.file.TimeStampingFileContext
# jvm.fileName=/tmp/metrics_jvm.log  # 这样JVM监控信息相关数据会发送到本地文件。

自定义Metrics的方式

很多情况下，我们希望从HBase中获取我们更加感兴趣的值，或者我们把这些监控信息发送到其它节点上去。实际上，这些工作都可以借助原有的HBase Metrics的框架来实现。

整个过程大概需要这么几步：

1）在AbstractMetricsContext类的继承实现相关的doUpdater方法。

2）配置相关的hadoop-metrics.properties的配置项。