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的可用和读写状况。==>对应分析中前两个问题。



使用方法：



U

sage: 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)

 



执行${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无法工作，会造成此现象。