名词解释：
JMX：Java Management Extensions，用于用于Java程序扩展监控和管理项。
GC：Garbage Collection，垃圾收集，垃圾回收机制。
1、概述
说到对Hadoop和 HBase的集群监控，大家知道的和用的最多的可能还是第3方的监控工具，cacti，ganglia，zabbix之类的。其实Hadoop本身是带有监控接口的，这个接口非常详细，也非常方便，就是JMX。
JMX全称是Java Management Extensions，用于Java程序扩展监控和管理项。而许多Hadoop系统都提供了丰富的JMX监控项，所以我们可以直接从HBase系统本身提供的JMX信息获取我们需要的监控项。HJMX web页面的数据格式是 json 格式。
2、指标来源
hbase的jmx在1.0后分开了master和regionserver的jmx监控。
启动 HBase 后，如果要查看查看 Master 的指标，请连接到 Master 的 Web UI， 默认为 http:// localhost:60010 或 HBase 1.0+中的端口 16010）
如果要查看查看 regionServer的指标，请访问区域服务器的 Web UI，默认情况下为 http:// REGIONSERVER_HOSTNAME:60030 （或 HBase 1.0+中的端口 16030）。
小技巧：
如果想要在列表中包含指标描述 - 这在你探索可用内容时非常有用，添加查询字符串?description=true，如： http://REGIONSERVER_HOSTNAME:60030/jmxdescription=true 。并非所有 bean 和属性都有描述。
由于信息比较多，也提供了一个qry=name的方式获取具体某一项所需的数据，例如：http://namenode:50070/jmx?qry=hadoop:service=NameNode,name=NameNodeInfo只收集namenode相关的数据。
所以我们可以用多线程或多进程同时采集多个指标项，同时也要注意在每个线程处理的时候数应该是异步的，否则同步可能导致某一个指标项采集阻塞， 使得之后的所有指标项在一个采集周期内无法正常返回数据。
3、监控指标说明
（1）主机基本监控项
CPU，内存，磁盘，网络 主机四大基本监控项，这4项机器监控保证我们运行我们HBase集群的机器是正常的。
数据来源：获取对象为java.lang:type=OperatingSystem，我们以http://xxxxxx:60010/jmx?qry=java.lang:type=OperatingSystem为例，可以访问到如下信息：
| 指标项 | 说明 |
|---|---|
| FreePhysicalMemorySize | 空闲物理内存大小 |
| ProcessCpuLoad | 进程cpu使用率 |
| SystemCpuLoad | 系统cpu使用率 |
| AvailableProcessors | 处理器核数 |
（2）JVM监控项
HBase 集群涉及的系统 HDFS，HBase，ZooKeeper都是用 Java 编写的，运行在 JVM 中，必须采集 JVM 相关的监控项。 Hbase 中对于 JVM 的监控数据，主要是 JvmMetrics 的对象来进行的。
JvmMetrics 主要统计的信息包括：内存的使用状态信息； GC 的统计信息；线程的统计信息；以及事件的统计信息。
数据来源：获取对象为Hadoop:service=HBase,name=JvmMetrics，我们以http://xxxxxx:60010/jmx?qry=Hadoop:service=HBase,name=JvmMetrics为例，可以访问到如下信息：
| 类型 | 指标项 | 说明 |
|---|---|---|
| 内存 | MemNonHeapUsedM | JVM 当前已经使用的 NonHeapMemory 的大小 |
| 内存 | MemNonHeapMaxM | JVM 配置的 NonHeapMemory 的大小 |
| 内存 | MemHeapUsedM | JVM 当前已经使用的 HeapMemory 的大小 |
| 内存 | MemHeapMaxM | JVM 配置的 HeapMemory 的大小 |
| 内存 | MemMaxM | JVM 运行时的可以使用的最大的内存的大小 |
| GC | GcCountParNew | 新生代GC次数 |
| GC | GcTimeMillisParNew | 新生代GC耗时(ms) |
| GC | GcCountConcurrentMarkSweep | 老年代GC次数 |
| GC | GcTimeMillisConcurrentMarkSweep | 老年代GC耗时 |
| 线程 | ThreadsNew | 当前线程的处于 NEW 状态下的线程数量 |
| 线程 | ThreadsRunnable | 当前线程的处于 RUNNABLE 状态下的线程数量 |
| 线程 | ThreadsBlocked | 当前线程的处于 BLOCKED 状态下的线程数量 |
| 线程 | ThreadsWaiting | 当前线程的处于 WAITING 状态下的线程数量 |
| 线程 | ThreadsTimedWaiting | 当前线程的处于 TIMED_WAITING 状态下的线程数量 |
| 线程 | ThreadsTerminated | 当前线程的处于 TERMINATED 状态下的线程数量 |
| 事件 | LogFatal | 固定时间间隔内的 Fatal 的数量 |
| 事件 | LogError | 固定时间间隔内的 Error 的数量 |
| 事件 | LogWarn | 固定时间间隔内的 Warn 的数量 |
| 事件 | LogInfo | 固定时间间隔内的 Info 的数量 |
（3）HBase集群各系统存活监控项
HBase集群各个系统的进程是否存活是必须也是最基本的监控项。具体有hmaster；regionserver；namenode；datanode；journalnode；zkfc；zookeeper的存活监控。
具体判断存活的方式我们可以去判断各系统相应的进程是否存在，也可以去判断各系统的web页面或者jmx页面是否正常。
3.1 master监控
数据来源：获取对象为Hadoop:service=HBase,name=Master,sub=Server，我们以http://xxxxx:60010/jmx?qry=Hadoop:service=HBase,name=Master,sub=Server为例，可以访问到如下信息：
| 指标项 | 说明 |
|---|---|
| tag.liveRegionServers | 活动的region |
| tag.deadRegionServers | 停止的region |
3.2 regionserver监控
3.2.1 每个表每个region的数据
数据来源：获取对象为Hadoop:service=HBase,name=RegionServer,sub=Regions，我们以http://xxxx:60030/jmx?qry=Hadoop:service=HBase,name=RegionServer,sub=Regions为例，可以访问到如下信息（以下仅展示一部分）：
指标项说明
每个表每个region的的指标项说明
第一个xxx代表namespace名
第二个xxx代表表名
第三个xxx代表region的ID
| 指标项 | 说明 |
|---|---|
| Namespace_xxx_table_xxx_region_xxx_metric_storeCount | Store个数 |
| Namespace_xxx_table_xxx_region_xxx_metric_storeFileCount | StoreFile个数 |
| Namespace_xxx_table_xxx_region_xxx_metric_memStoreSize | memStrore大小 |
| Namespace_xxx_table_xxx_region_xxx_metric_storeFileSize | storeFile大小 |
| Namespace_xxx_table_xxx_region_xxx_metric_compactionsCompletedCount | 合并完成次数 |
| Namespace_xxx_table_xxx_region_xxx_metric_numBytesCompactedCount | 合并文件总大小 |
| Namespace_xxx_table_xxx_region_xxx_metric_numFilesCompactedCount | 合并完成文件个数 |
3.2.2 每个regionserver的监控数据
大致分为server、IPC、WAL、Memory、MemoryPool四类，数据较长，以下仅展示一部分
下面介绍一些最重要的 RegionServer 指标（摘自HBase官网）：
hbase.regionserver.regionCount：区域服务器托管的区域数量
hbase.regionserver.storeFileCount：当前由 regionserver 管理的磁盘上的存储文件数
hbase.regionserver.storeFileSize：磁盘上存储文件的聚合大小
hbase.regionserver.hlogFileCount：尚未归档的预写日志数
hbase.regionserver.totalRequestCount：收到的请求总数
hbase.regionserver.readRequestCount：收到的读取请求数
hbase.regionserver.writeRequestCount：收到的写入请求数
hbase.regionserver.numOpenConnections：RPC 层的打开连接数
hbase.regionserver.numActiveHandler：主动为请求提供服务的 RPC 处理程序的数量
hbase.regionserver.numCallsInGeneralQueue：当前排队的用户请求数
hbase.regionserver.numCallsInReplicationQueue：从复制中收到的当前排队操作的数量
hbase.regionserver.numCallsInPriorityQueue：当前排队的优先级（内部管家）请求的数量
hbase.regionserver.flushQueueLength：memstore 刷新队列的当前深度。如果增加，我们落后于清除 HDFS 的存储库。
hbase.regionserver.updatesBlockedTime：已阻止更新的毫秒数，因此可以刷新 memstore
hbase.regionserver.compactionQueueLength：压缩请求队列的当前深度。如果增加，我们落后于 storefile 压缩。
hbase.regionserver.blockCacheHitCount：块缓存命中数
hbase.regionserver.blockCacheMissCount：块缓存未命中数
hbase.regionserver.blockCacheExpressHitPercent：打开缓存请求的时间百分比达到缓存
hbase.regionserver.percentFilesLocal：可从本地 DataNode 读取的存储文件数据的百分比，0-100
hbase.regionserver. <op>_<measure></measure></op>操作延迟，其中<op>是 Append，Delete，Mutate，Get，Replay，Increment 之一;其中<measure>是 min，max，mean，median，75th_percentile，95th_percentile，99th_percentile</measure> </op>中的一个
hbase.regionserver.slow <op>计数</op>：我们认为操作的数量很慢，其中<op>是以上列表中的一个</op>
hbase.regionserver.GcTimeMillis：垃圾收集所花费的时间，以毫秒为单位
hbase.regionserver.GcTimeMillisParNew：在年轻一代的垃圾收集中花费的时间，以毫秒为单位
hbase.regionserver.GcTimeMillisConcurrentMarkSweep：在旧一代的垃圾收集中花费的时间，以毫秒为单位
hbase.regionserver.authenticationSuccesses：身份验证成功的客户端连接数
hbase.regionserver.authenticationFailures：客户端连接验证失败的次数
hbase.regionserver.mutationsWithoutWALCount：提交的写入计数带有一个标志，指示它们应绕过写入日志
IPC类：
TotalCallTime_mean：总调用耗时(包括队时间和处理时间)
TotalCallTime_95th_percentile：调用P95耗时(包括队时间和处理时间)
TotalCallTime_99th_percentile：调用P99耗时(包括队时间和处理时间)
QueueCallTime_mean：队列调用耗时
