HBase 运维分析

问题分析的主要手段

1、监控系统：首先用于判断系统各项指标是否正常，明确系统目前状况

2、服务端日志：查看例如region移动轨迹，发生了什么动作，服务端接受处理了哪些客户端请求。

3、gc日志：gc情况是否正常

4、操作系统日志和命令：操作系统层面、硬件是否故障，当前状况如何

5、btrace：实时跟踪目前服务端的请求和处理情况

6、运维工具：通过内置于系统中的功能，查看服务器实时处理状况

其实以上手段，大部分系统都具备，不过各有各的用法，下面我会通过常见的问题来梳理这6大手段。

 

常见问题1：个别请求为什么很慢？

个别请求慢是用户遇到最多的问题，首先需要明确是客户端还是服务端原因，进而分析服务端状况以及捕获这些请求来明确定位。

1、通过客户端日志来初步分析下慢请求的规律，尝试在客户端确定请求的rowkey和操作类型。

2、确定是不是一段时间内集中出现慢请求，如果是那么可以参考常见问题2来解决。

3、查看服务端监控，观察响应时间是否平稳，maxResponseTime是否出现峰值。如果存在，那么可以初步确定是服务端问题。

4、客户端分析无效，可以通过运维工具在服务端捕获慢请求的rowkey和操作类型。

5、确定rowkey对应的region，初步查看是否存在数据表参数配置不合理（例如version设置过多、blockcache、bloomfilter类型不正确）、storefile过多、命中率过低等问题。

6、尝试重试这些请求或者直接分析hfile来查看返回结果是否过大，请求是否耗费资源过多。

7、查看服务端关于hdfs的监控和日志，以及datanode日志，来分析是否存在hdfs块读取慢或者磁盘故障。

 

常见问题2：客户端读写请求为什么大量出错？

读写请求大量出错的现象主要有两类：1、大量出现服务端exception 2、大量超时。其中第一种有异常信息较好判断问题所在。

1、大量服务端exception一般是region不在线导致的，可能是region在split但是时间很长超过预期，或是meta数据错误导致客户端获取region location错误。以上现象均可通过日志来定位。

2、遇到大量超时，首先应该排除服务端是否出现了fullgc或者ygc时间过长。前者可能由于内存碎片、cms gc速度来不及导致，后者一般是由于系统使用了swap内存。

3、通过系统命令和日志来查看是否有机器load过高，磁盘压力过大，磁盘故障。

4、查看监控是否出现callqueue积压，请求无法得到及时处理，进一步通过call查看工具或者jstack可以查看正在处理的call和进程堆栈信息。

5、通过datanode日志和hbase访问dfs的时间，来判断问题是否在hdfs层。

6、查看监控判断是否出现blocking update，memstore是否已接近系统设置的上限。

 

常见问题3：系统为什么越来越慢了？

系统原来挺快的，为什么越来越慢？多数是不合理的服务端配置导致的，可以通过以下几个方面来分析。

1、磁盘读写和系统load是不是比以前高了，初步判断导致系统变慢的原因。

2、如果磁盘读写加剧，重点查看flush是否过小，compact是否过频，尤其是major compact是否有必要，从测试结果来看compact产生的磁盘io对系统性能影响很大。

3、单个region的storefile个数是否有成倍提高

4、命中率是否有下降趋势

5、regionserver是否存在region分配不均衡导致的读写集中，或者读写handler的竞争

6、datablock的本地化率是否出现下降

7、是否存在datanode运行不正常，可以通过监控查看是否有个别机器读取block时间明显偏高

 

常见问题4：数据为什么没了，明明写进去过？

数据丢失也是HBase的常见bug，分为临时性和永久性两类。临时性的丢失往往是由于hbase本身的正确性问题导致瞬间读取数据错误。永久性丢失一般是日志恢复bug或者region的二次分配。

1、首先可以通过hbck或者master日志排查丢失的数据所在region是否发生过二次分配

2、集群中的regionserver是否出现过abort，日志是否正确恢复。

3、扫描storefile确定目前数据情况

4、扫描logs或者oldlogs中的文件来确定是否写入过这些数据，以及写入数据的时间，配合rs的日志来确定当时server的行为

5、根据写入数据的时间，确定regionserver是否正确完成了flush并且将数据写入磁盘

 

常见问题5：为什么有服务器进程挂了？

 regionserver发生abort的场景很多，除了系统bug引起的以外，线上遇到最多的就是fullgc引起的zk节点超时和文件系统异常。

1、查看regionserver日志查询FATAL异常，确定异常类型

2、查看gc日志确定是否发生fullgc或者ygc时间过长

3、如果没有征兆，日志突然中断，首先需要考虑是否发生了OOM（0.94版本会直接kill -9）。

4、可以通过系统内存监控判断是否出现被占满的情况

5、查看datanode是否出现异常日志，regionserver可能由于roll log或者flush时的文件系统异常导致abort

6、排除人为调用stop的情况

 

HBase健康体检

一个集群似乎否健康，大体可以从以下几个方面来判断

1、单region的storefile数量是否合理

2、memstore是否得到合理的利用，此项指标与hlog的数量和大小相关

3、compact和flush的流量比值是否合理，如果每天仅flush 1G却要compact几十上百G就是明显的浪费

4、split似乎否过频，能否采取pre-sharding的方式来预分配region

5、集群的region是否过多，zk在默认参数下无法支撑12w以上的region个数，并且region过多也会影响regionserver failover的时间

6、读写相应时间是否合理，datablock的读取延时是否符合预期

7、flush队列、callqueue长度、compact队列是否符合预期。前两者的积压都会造成系统不稳定。

8、failedRequest和maxResponseTime

9、gc状况，过长的ygc和过频的cms都需要警惕

 

运维工具

HBase官方版本的可运维性的确很差，为了能最大限度的保证线上系统安全，快速定位故障原因，阿里做了很多建设性的工作。

1、建立了完整的监控体系，根据日常测试和线上运行经验，加入了很多监控点。

2、监控的粒度达到region级别

3、call dump和线上慢请求追踪功能

4、btrace脚本体系，出现问题直接运行查看程序内部信息

5、日志收集和报警

6、在线表维护工具和storefile、logs分析工具

本文转载自：http://www.taobaotesting.com/blogs/2158