1、背景
随着大数据表格应用的驱动，我们的HBase集群越来越大，然而由于机器、网络以及HBase内部的一些不确定性的bug，使得系统面临着一些不确定性的故障。
因此，HBase上有很多的Region组成，需要控制每个表格的Region的状态。
分析：
1）实时掌控Region的状态。应用的每次访问要直接与HBase某个Region关联，需要探测Table上Region是否处于可用状态。
2）Region的读写与底层的HDFS的状态相互关联。这种关联决定了通过Region的读写状况的监控，也可以反映HDFS的状况。
2、实战工具
org.apache.hadoop.hbase.tool.Canary 监控Region的可用和读写状况。==>对应分析中前两个问题。
使用方法：
Usage: bin/hbase org.apache.hadoop.hbase.tool.Canary [opts] ]
where [opts] are:
-help Show this help and exit.
-daemon Continuous check at defined intervals.
-interval <N> Interval between checks (sec)
where [opts] are:
-help Show this help and exit.
-daemon Continuous check at defined intervals.
-interval <N> Interval between checks (sec)
执行${HBASE_HOME}/bin/hbase org.apache.hadoop.hbase.tool.Canary
在不同配置情况下对集群内所有的Table进行探测，探测的结果如下：
它默认会取出Region的startKey,按照ColumnFamily分别执行一次Get操作，并打印出系统的延迟。对于Region出问题的情况下，会打印出failed的状态。
然而这个工具仍然存在不足：
1）无法提供Region服务异常的实时报警。
2）未提供对于延迟的监控与报警。
我们在代码里添加了相应的报警功能，每次探测一次，找出延迟超过最高限或者Region有问题的Table，并通过邮件或者Message及时告警。
ps：为了增加监控的智能反应，在出现hfile文件无法seek或者Region offline的情况下，程序会通过HBaseAdmin.assign(regionName)接口重新部署一次Region，可以避免如下的异常：
1）Region上storefile不一致。例如，storefile list中文件与hdfs上的文件没有对应上。这种问题可能会在系统Compaction异常或者split操作过程中出现，重新assign会重新加载这部分的数据，即可避免此问题。
2）Region处于Offline状态。例如RS下线，HMaster宕机的情况下，AM无法工作，会造成此现象。
备注：
本系列文章属于
Binos_ICT在
Binospace个人技术博客原创，原文链接为
http://www.binospace.com/index.php/hbase-combat-series-2-region-monitoring/
，未经允许，不得在网上转载。
From Binospace, post HBase实战系列2—Region监控
文章的脚注信息由WordPress的wp-posturl插件自动生成