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

备注:本文描述了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将会使用新的监测系统。接下来还有很多工作要做,但我们已经取得了很大的进展。

原文链接: Apache HBase Blog 翻译: ImportNew.com - 陈 晨
译文链接: http://www.importnew.com/4895.html
[ 转载请保留原文出处、译者和译文链接。]

关于作者: 陈 晨

致力于互联网大型分布式领域,实践各种软件过程与自动化。爱生活,爱JAVA。新浪微博: 一酌散千忧

查看陈 晨的更多文章 >>



相关文章

发表评论

Comment form

(*) 表示必填项

还没有评论。

跳到底部
返回顶部