HBase 监控及优化

最近有一些时间，一直在想，如果有几百台甚至上千台Hadoop集群，需要怎么来监控？ 监控的意义是为了了解整个集群的状态是否良好，以便考虑是否需要扩容，配置是否需要调整等等。但是如果几百台上千台集群，即使我们有监控，怎么能够快速了解集群状态呢？ 以下我自己根据我自己一些经验来谈谈，我们拿HBASE来做例子，之前我写了几篇对HBASE内部分析的文章，但只涉及部分HBASE的东西，希望今天能更全面一点。

在说具体的监控及优化之前，先要阐述一下我的理念：我从来不相信任何一个参数或者几个参数的改变能够对集群造成极大的性能提高。我说的不是指HADOOP，我是说所有的系统。每个人的环境不同，机器性能配置不同，业务模式不同，我们只有依赖监控获得的状态，加上我们对系统原理的了解，这2者合为一体的进行分析，才能够对系统进行优化，否者优化什么？ 

回到HBASE的监控，既然要监控，那就有具体监控的参数，整个HADOOP系统都有metric，我们只要打开官方文档或者通过jconsole查看某个服务器的metric，就能够知道HBASE整体监控分为2个部分，JVM和regionServer， 细分也就以下几个：

1. JVM

2. IPC

3. region

4. Server

5. WAL

HBASE整体访问流程是接受到请求之后，(hbase.ipc.server.read.threadpool.size)把请求放入到队列当中，然后有handler(hbase.regionserver.handler.count)从队列当中去处理请求, 请求无非就是get, put, scan等语句，在处理过程当中就会与系统内部结合，比如写WAL，memstore, flush到HFILE, 合并文件，分裂文件，这一系列过程在接受到请求就同步发生了。

JVM是监控内容的基本，必须要了解HBASE JVM的内存使用量，高峰低峰什么情况，以及GC情况。JVM的heap一般划分为2个模块，memstore和block cache, 这个之前文章已经谈过了。 block cache存储的内容为：HFILE INDEX, data block，bloom filter, rowkey, hbase-meta。block cache(L1  cache) 主要存储还是 data block, 由于 data block很容易刷新出去，这样会导致经常GC，为了获得更好的性能，hbase又提供了一个 bucketcahce（L2 cache)，默认是不启用的。根据理论解释，如果你的环境data block如果刷出去的频率比较高，那么开启bucket cache, 如果刷出去频率比较低，那么可以不开启。 bucket cache是不走GC的，它是一个file-based（Java direct memory)的缓存。如果开启了这个参数，那么data block就会存储到bucket cache, block cahce里就只有INDEX，bloom filter等.  memstore就是存储新插入的数据，并写入WAL，达到一定条件就flush成 HFILE，由于之前HBASE容易发生内存碎片，后来打了mslab patch，也就是说每个memstore会有一个mslab实例，默认2M，默认现在都是开启的，大家可以去参考资料了解。

要了解内存的使用以及状态，属先看memstore，默认128M，你在高峰的时候随便从几台机器查看日志，看看flush的时候是否为128M，如果小于128很多，比如只有40M，这就说明memstore总内存是不够的，算法很简单，heap*0.6/total active region， 为什么会小于默认值，是因为你的并发region很多，导致没有那么多内存用，那么hbase默认只能根据内存实际情况去刷新memstore, 还有一种情况memstore刷新值大于默认值，这个情况是因为插入量相当大，瞬间撑破了默认值。2者的区别很容易分辨。 

那么block cache的使用先参考命中率，一般HBASE的命中率可能不会很高，也就60%，差点的30%，这个时候你就要考虑是否开启bucket cache, 另外检查HFILE INDEX的大小，通过WEB UI很容易查看，统计一下你现在的内存到底够不够用。整体内存的监控是比较简单的。

一个regionserver能够处理的请求和CPU,内存相关，比如hbase.regionserver.handler.count设置多少合理？ 10，50，100？不知道，在没有合理的监控基础上，你怎么知道？ 这个参数的含义是处理HBASE内部处理前台请求的参数，并发越高，自然占用CPU，内存就越多，这个值到底多少合理，有人给出100-200的建议，请问这个建议怎么来的？ 那是人家的机器配置和业务模式，不是你的，你必须根据你目前JVM的监控，内存占用量，机器load来判断，假设你现在设置为100，你最顶峰的时候内存占用8个G，机器负载也就10%，很显然，你可以增加这个参数，假设你顶峰的时候内存占用了80%甚至经常full GC, 你还敢加这个参数？ hbase.ipc.server.read.threadpool.size是用来把前端请求放到队列中的参数，HADOOP系统内部都是通过RPC框架来请求资源的。默认这个参数应该是10，10个够不够，还是不知道，看整体并发，监控metric: numActiveHandler 解释：Number of active rpc handlers.  如果这个值经常满，那么就需要增加。

至于regionserver后端处理的文件合并，分裂就不谈了，之前的文章有聊过。

通过jmx查看各种metric，找到自己想要监控项，监控起来，我自己的办法是jmxtrans+influxDB+grafana， 但是只监控了一部分，有一部分可以在web UI看到的，就没有做监控了。grafana也能触发alter，可以在比较重要的metric设定一个alter,用来报警。