HBase：迁移到新的监测系统——Metrics2

本文由 ImportNew - 陈 晨 翻译自 Apache HBase Blog。如需转载本文，请先参见文章末尾处的转载要求。

备注：本文描述了HBase的服务端代码。阅读本文的前提是读者需要具备对于系统的大致了解。你能够在这里读到更多关于HBase的文章。

介绍

HBase是根据Google BigTable论文实现的一个分布式海量数据存储模型。与所有分布式系统类似，了解系统在给定时间里正在发生什么对提前发现问题、调试当前问题、评估新的使用模式以及提供容量规划的依据有很大帮助。

从2008年10月0.19.0版本，(HBASE-625) HBase就开始使用Hadoop的metrics系统导出监测信息到JMX、Ganglia或其他监测接收器。随着代码库增长，不同的开发者加入了更多的监测。新特性都被加上了对应的监测。用户在处理问题时需要更多的数据，于是加入了更多的监测插件。这些新监测插件的命名并不规范而且其中的一些没有文档。

随着HBase的监测系统功能不断增长，Hadoop开发者们开发了一个叫做Metrics2的新Metrics系统。在HADOOP-6728及随后的JIRAs中，建立了一个新版本的Metrics系统。新的子系统有新的命名空间、不同的Sinks、不同的源码以及更多的特性，并且比老的监测系统更加完整。当Metrics2完成后，就会废弃Metrics1。了解了上述信息，也是时候更新HBase的Metrics系统了，所以HBASE-4050启动了。同时也希望借此清理代码中累积下来不规整的实现。

定义

实现细节中有许多难懂的术语，本文中的定义如下：

• Metric：系统中的属性度量
• Snapshot：在某一给定时间点的Metrics的集合
• Metrics1：老的Apache Hadoop metrics 系统
• Metrics2: 全新修复 Apache Hadoop Metrics 系统
• Source: 将监测信息展示给 Hadoop metrics 系统的类
• Sink: 从Hadoop metrics 系统接收metrics快照的类
• JMX: Java管理扩展。Java的内建系统，促进基于网络的java进程管理；包含展示metrics的功能。
• Dynamic Metrics: Metrics 包括很多。Metrics 也不是都在编译时获取，也会在运行时获取。

实现

Hadoop Metrics2系统在branch-1 和branch-2中的差别很大，这意味着一个独立实现的代码想从metrics迁移至metrics2 sinks可能无法实施或者无法很简单的实施。因此我构建一个不同的Hadoop兼容性系统，能够在运行时加载版本。这样当branch-1 和 branch-2中关联Hadoop的部分改变后就能使用ServiceLoader来对任何类构建实例。

举例：一个域服务器能够通过Hadoop2版本的shim来展示关于HRegionServer的监测信息。（Hadoop1的兼容性jar包使用虚线表示，若使用Hadoop1可以切换）

本系统运行HBase同时支持Hadoop 1.x和Hadoop 2.x，不需要通过反射或者其他方式来取得不同API、使用方式或命名空间。

现在HBase能够使用Hadoop 1 或者 Hadoop 2的metrics2系统，我设置整理了HBase的监测可展示项、如何展示、命名和收集数据的性能。

Metrics2使用注解或源码来展示监测信息。自从HBase不能在核心代码中包含metrics2系统的任何部分开始，我就通过构建源码来展示HBase的所有监测信息。Metrics2访问构建HBase核心部分的封装类获取监测值。下图的例子是展示HRegionServer的监测（非动态监测）是如何展示的：

上述模式能够反复使用用于展示HBase的大量监测信息。尽管特定域的监测仍然十分有趣，但无法按照上述的模式展示。所以我们需要一个新的解决方案，无论域中哪台作为主域服务器都可以展示监测信息。为了能够应付更复杂的情况，Hadoop metrics2 系统需要一个MetricsSource （监测源）通过JMX的mbean负责所有节点的监测信息展示。为了能够将所有域的监测信息展示，HBase需要将多个域的监测信息合并到一个源中展示。这个源需要负责了解哪个域被分配给了域服务器。这样需要有一个合并信息源，能够包含每个域的源。这些源包含对域监测信息的封装。如下图所示：

优点

翻新一个之前能够正常运行的监测系统有很大的工作量，那么我们这么做有什么意义呢？进行整个系统单元测试和系统测试会变得更加容易，系统会变得更加规范所有组件都遵循相同的模式和命名规则。最后，所有的部分都被重写并且更高效。

之前按照需要添加的监测插件没有都按照规范格式命名。有一些按照“metricNameCount”方式命名，有些按照“numMetricName”，还有些按照“metricName_Count”。这样会造成转换困难，而且管理混乱。整理之后，一个计数器按照骆驼命名法且后缀为“Count”。Mbeans也缺少规范。有些监测会散布在两个mbean中。在mbean中，监测一个域的插件命名为Dynamic，而不是一个最适合理解的名字。现在mbean组织的更好，也有更准确的描述了。

测试发现，替换了老的HBase监测系统之后，单个进程扫描效率提高了9%。老系统使用ConcurrentHashMap存储动态监测信息。所有访问等操作需要在这些巨大的hash表中查找。新系统最小化了map的使用。取而代之的是每个域或服务器将监测信息导出至伪数据源。在监测系统中，唯一的改变发生在域的开关上。

结论

总而言之整个系统变得更好了。整个过程耗时而且很辛苦，但是很值得。使得HBase的监测系统整体处于一个更好的状态了。HBase 0.95 和之后的 0.96将会使用新的监测系统。接下来还有很多工作要做，但我们已经取得了很大的进展。

-- 扫描加关注，微信号: importnew --

原文链接： Apache HBase Blog 翻译： ImportNew.com - 陈 晨
译文链接： http://www.importnew.com/4895.html
[ 转载请保留原文出处、译者、译文链接和上面的微信二维码图片。]

相关文章

• HBase数据迁移（3）-自己编写MapReduce Job导入数据
• HBase数据迁移（2）- 使用bulk load 工具从TSV文件中导入数据
• HBase数据迁移（1）
• 为Hbase建立高可用性多主节点
• HBase推荐书籍列表
• JVM垃圾回收机制
• 有效处理Java异常三原则
• Scala集合（二）
• 你应该关注的几个Eclipse超酷插件
• Java9 javac 将不再支持Java 1.5以及更早的代码