HBase监控与调优实战：从关键指标到延迟排查的完整指南

开头先说个我印象特别深的场景：某天下午，业务方跑过来跟我说“HBase集群是不是挂了”，我打开监控面板一看，CPU不高、内存剩很多、磁盘也没满，RegionServer每个节点的指标都“挺正常”的，但业务侧的写延迟就是从个位数毫秒涨到了几百毫秒。这种“看着没毛病，用起来卡成狗”的情况，恰恰是HBase监控与调优最典型、也最让人头疼的地方。

这篇文章我从实际运维的角度，把HBase监控与调优的关键指标、工具选型、调优动作讲清楚。不是罗列一堆参数让你死记硬背，而是告诉你每个指标到底在反映什么问题、什么情况下才需要动作、怎么从“看到数字”推到“做出调整”。适合正在维护HBase集群的运维同学，也适合刚接手集群、想建立一套靠谱监控体系的初学者。

1. 监控架构先分层：OS、JVM、HBase各自的指标图谱

1.1 为什么监控必须分层看

很多人调HBase只看HBase自带的Web UI，RegionServer页面打开一看，请求数、堆内存、缓存命中率都有，好像挺全面。但这里有个大坑：HBase一次读写的完整链路，从客户端到ZooKeeper协调，再到RegionServer处理，最后落到HDFS的DataNode上，中间任何一层出问题，最终都只会表现为“HBase请求延迟变高”。

我以前带过一个同学，他排查慢查询时只盯HBase的RPC处理时间，发现处理时间很高，就开始调RegionServer的线程池、调并发，折腾了大半天。后来我让他去看底层文件系统的IO状况，发现是某台DataNode的磁盘在老化，IO util经常打到90%以上，慢的全是这台机器上的Region。问题根本不在HBase配置，而在存储层。

所以监控一定要分层。我的习惯是分三层：

• OS层：CPU、内存、磁盘IO、网络，这层的异常往往来自硬件、宿主机争抢或者系统参数。
• JVM层：堆内存、GC频率和停顿、线程状态，RegionServer是一个Java进程，它的“健康度”直接由JVM决定。
• HBase层：RegionServer、Master、表级别的业务指标，这层反映的是服务本身的运行状态。

三层都要有数据，排查时才能从上往下或者从下往上逐层定位。哪一层缺失，遇到问题就只能瞎猜。

1.2 OS层要看的指标

OS层最容易忽略的是磁盘的await和util。很多人看磁盘只看空间够不够，忽略延迟。HBase的WAL（Write-Ahead Log）是同步刷盘的，一条写请求要先把日志落盘才算成功，磁盘延迟稍微一抖，写延迟就直接被拉高。所以我会长期记录每台DataNode和RegionServer所在物理机的磁盘延迟曲线，一旦await开始持续上涨，就要去查是不是磁盘快满了、有坏道，或者是宿主机上其它虚拟机在抢IO。

CPU方面不要只盯着平均负载。对于RegionServer来说，更值得关注的是sys（内核态）占比。如果sys一直很高，通常意味着系统调用频繁、锁竞争严重，这种时候堆内存可能还有富余，但请求就是快不起来。

网络层看TCP重传率。HBase节点之间、客户端和RegionServer之间的通信量很大，TCP重传率异常升高时，表现为请求偶发超时，但CPU、IO全都很正常。这类问题不做网络层监控很难发现。

1.3 JVM层要看的指标

JVM层的关键词就一个：GC。RegionServer是长驻内存的Java服务，最怕的就是GC停顿。Full GC一停就是几秒钟，期间该RegionServer上所有Region的租约可能都超时了，客户端会重试，后果是写放大和请求雪崩。

具体看什么？我建议至少盯三样：

• Full GC频率：从“一天几次”到“一小时几次”，是质变。
• Full GC单次停顿时间：超过2秒就要拉警报。
• Young GC频率：频繁的Young GC虽然单次很短，但说明对象分配太快，往往会伴随内存参数不合理。

JVM层还有一个容易被忽略的指标是线程数。RegionServer的RPC线程、Flush线程、Compaction线程如果长期处于高水位或者频繁创建，很可能有线程泄漏或者线程池配置不当。一般监控不会单独收集线程数，我是在出问题时才用jstack去抓线程快照，平时靠进程级监控兜底。

1.4 HBase层要看的指标

HBase层我只看几类：状态类、队列类、耗时类、数量类。

状态类包括RegionServer是否在线、Region是否处于过渡状态（比如分裂中、正在打开）、Master是否在active状态。这些是“死了还是活着”的问题，优先级最高。

队列类包括RPC队列长度、Flush队列长度、Compaction队列长度。队列堆积说明处理速度跟不上请求速度，是延迟的直接来源。

耗时类比队列更能反映真实体感，尤其是RPC处理时间、WAL同步耗时、读请求的延迟分位数。我会同时记录均值、P95和P99，只看均值会把长尾问题掩盖掉。

数量类包括Region数量、每个Store的HFile数量、BlockCache命中率。数量类指标看着不痛不痒，但它们是调优动作的直接依据，比如Region数量太多就要做拆分或合并，HFile太多就要考虑Compaction策略。

2. 需要长期盯住的关键指标与合理阈值设定

2.1 RegionServer级别：写路径指标

写路径上，最先看的是WAL同步耗时。HBase的HLog在每次写入时都会同步到HDFS，这个“同步”动作的耗时基本决定了写延迟的下限。如果WAL的P99超过50毫秒，大概率是磁盘IO或者网络有问题，而不是HBase参数的问题。

接着看Memstore的使用情况。单RegionServer默认有40%的堆内存给Memstore，当Memstore总量超过hbase.regionserver.global.memstore.size的限制后，写入就会被阻塞，强制触发Flush。这个指标接近限制值甚至频繁触发Flush时，写吞吐会明显下降。更麻烦的是，Memstore长时间高水位意味着Flush线程在加班，会让后续的HFile数量不断攀升，形成连锁反应。

Flush队列长度也可以当作预警指标。正常情况下队列接近0，持续大于几十说明Flush速度跟不上写入速度，这是写阻塞的前兆。我见过不少集群，业务还在正常跑，Flush队列已经积压了上百个请求，这时距离写失败就差一步了。

2.2 RegionServer级别：读路径指标

读路径最重要的就是BlockCache命中率。HBase的读请求先查BlockCache，命中就直接返回，没有命中才去读HFile。命中率掉到90%以下，读延迟大概率会明显上升，因为每次读都要涉及磁盘IO和文件寻址。

再就是StoreFile（HFile）数量。每个Store里的HFile越多，一次读操作要合并的文件就越多，扫描成本越大。一般建议单个Store的HFile数量维持在个位数，如果长期在20个以上，说明Compaction进度跟不上写入速度，读路径迟早要出问题。

Region数量也要盯。单个RegionServer上Region太多（我习惯以超过1000为警戒线），一方面内存碎片化严重，另一方面Region分裂、合并等管理动作会更频繁，挤占正常的请求处理资源。

2.3 Master级别和表级别指标

Master层面的指标经常被忽略。Master负责Region分配、负载均衡、DDL操作，它挂掉或者卡顿不会立刻让读写中断，但会导致Region无法迁移、新表创建超时、均衡无法执行。盯两个：Master的RPC队列长度、Master进程的GC停顿。

表级别要关注请求量的倾斜程度。同一张表的不同Region，写请求量如果差好几倍，就是典型的热点Region。热点会导致单台RegionServer压力过大，其它节点闲着，集群整体能力上不去。

2.4 我用的一套阈值参考

下面这个表不是官方标准，是我在多套集群上验证过的经验值，可以直接拿去当初始阈值，跑一段时间后再根据自己集群的基线调。

这里想强调一句：阈值最重要是两点，一是要分P99和均值，二是要基于历史基线。直接套官方默认或者网上的推荐值，很容易误报或者漏报。我每次新建监控都会先静默采集两周数据，跑出每个指标的日常波动区间，再定告警阈值。

3. 监控采集与告警落地：自带UI、JMX到Prometheus体系

3.1 先用好HBase自带的Web UI和Metrics

很多团队一上来就上重型监控体系，其实HBase自带的东西已经能解决一半问题。Master UI上有整个集群的Region分布、RegionServer的负载情况、表的热点分布。点进单个RegionServer，能看到堆内存使用、BlockCache命中率、HFile数量、WAL写耗时。排障的第一步我都是先开UI看一圈，信息非常直观。

HBase底层是Hadoop的metrics2体系，所有核心指标都在里面。默认情况下这些指标会写到本地文件和JMX里。接其它监控系统时，最方便的是直接抓JMX，或者开启metrics2的定时输出文件，再由采集器拉取。

3.2 生产推荐：Prometheus + Grafana的组合

我不推荐在生产环境长期依赖HBase自带的UI，因为它只显示瞬时状态，没有历史曲线，没法看趋势。要快速定位“什么时候开始变慢”，必须要有历史监控。我自己在多数项目里用的是Prometheus+Grafana这套，被验证了很多次，可靠且坑少。

HBase接入Prometheus，最通用的事是走JMX Exporter。做法简单说三步：

1. 在每个RegionServer和Master的Java启动参数里，加入JMX Exporter的agent参数，让JVM暴露自定义端口。
2. 配置jmx_exporter的抓取规则文件，指定要暴露的指标名，比如Hadoop:service=HBase,name=RegionServer,sub=Server下的各种Metrics。
3. 在Prometheus的scrape_configs里加RegionServer和Master的targets，然后Grafana导入HBase相关的Dashboard模板。

需要特别注意，JMX Exporter的端口一定不要用默认的未授权访问，有网络暴露风险的时候，最好在防火墙层或者部署层面做限制。还有一点，JMX Exporter本身会占用一点内存，agent参数里最好把-Xms、-Xmx留点余量，别让JVM堆被agent挤占。

3.3 轻量方案：没有监控平台也能干

如果集群规模小，暂时上不了Prometheus整套，也可以走轻量方案。JDK自带jstat，定时把GC情况写到日志；再用HBase自带的Metrics输出，做一个简单的crontab脚本，把关键指标通过内部IM机器人和邮件发到运维群。这套方案能做到“有问题第一时间知道”，代价是历史曲线比较弱，但总比两眼一抹黑强。

3.4 告警规则设计上的经验

告警设计最容易犯的错误是“一个指标固定一个阈值”，结果就是告警风暴和漏报并存。我的原则是分三级：

• 提示级：指标从基线劣化，比如WAL耗时P99突破预警线，持续5分钟以上。
• 告警级：指标达到预警线，业务侧出现延迟上升，需要值班同事介入。
• 严重级：RegionServer下线、Full GC长时间停顿、Memstore写阻塞，需要立即响应。

另外，阈值一定要配“持续时间”。瞬时刺穿不告警，持续一段时间才触发，可以过滤掉大部分正常的毛刺抖动。我曾经因为没加持续时间，一个晚间批量任务触发IO抖动，整个群告警刷了一晚上，第二天就被人投诉了。

4. 指标驱动调优：几个高频场景的实操参考

4.1 Memstore与BlockCache比例：先从算账开始

调优不是拍脑袋。RegionServer的Java堆就像一个公共箱子里分了三块：BlockCache、Memstore、其余（索引、RPC缓冲、各种临时对象）。默认情况下，BlockCache占0.4，Memstore占0.4，看似公平，实际上大多数场景不是最优的。

如果集群是写多读少，Memstore分配太低会导致频繁Flush、写阻塞，这时候应该把Memstore调大，比如hfile.block.cache.size=0.3、hbase.regionserver.global.memstore.size=0.5。如果读多写少，则反过来把BlockCache调大。我的经验是两块加起来最好不超过0.7，给其它部分留出至少30%的空间，否则写并发一上来，堆的“其它”部分先爆掉，反而更容易触发GC。

具体修改时，两个参数是配置文件里的：

hbase.regionserver.global.memstore.size=0.4 hfile.block.cache.size=0.4

调完之后，观察三样东西：Full GC频率有没有变化、写请求的P99有没有下降、BlockCache命中率有没有下降。这三个指标，比看什么“理论最优配置”都准。

4.2 热点Region问题：预分区和RowKey设计

热点Region在监控上非常明显：某一个或几个Region的读写请求量是其它Region的数倍，对应RegionServer的CPU和IO也明显偏高。调优动作往往不在HBase参数上，而在RowKey设计上。

我当时处理过一个案例，业务把时间戳直接当RowKey前缀，结果所有写入都打到“当前时间”这个Region上，形成了最典型的热点。后来我们改成“设备ID哈希前缀+时间戳”的组合，将流量打散到多个预分区中，整集群的吞吐立刻翻了一倍。

如果RowKey已经不能改，可以考虑预分区并配合分裂策略。HBase默认的分裂策略是IncreasingToUpperBoundRegionSplitPolicy，它倾向于“越大越容易分裂”，但对热点场景不够灵敏。可以换成KeyPrefixRegionSplitPolicy，按前缀切分，让热点Region在可控的维度上分裂。

4.3 Compaction节奏控制：别让后台任务拖垮业务

Compaction是HBase后台最吃IO的任务，也是调优中最需要“看情况”的部分。当HFile数量持续增长、读延迟开始上升时，直观想法是加大Compaction线程数，让任务跑快点。但在业务高峰期，加大Compaction线程等于跟业务抢磁盘和CPU，结果往往是整体延迟一起涨。

更稳妥的做法是错峰调度：设置高峰期的Compaction开关或限制：

hbase.regionserver.thread.compaction.small=1 hbase.regionserver.thread.compaction.large=2

同时把hbase.hstore.compaction.max调小一点，让单次Compaction的合并不至于太激进，减少长尾IO。如果在离线低峰期，可以临时调大线程数，主动做一次major compaction，把HFile数量压下来。

这里有一个反直觉的点：Major Compaction不是做得越多越好。它本身会产生大量IO和写放大，频繁做反而可能让整个集群性能下降。我的建议是业务低峰期定期做，比如一周一次，平时靠Minor Compaction维持HFile数量就够了。

4.4 每次调优必须有验证闭环

我见过太多人改完参数就收工，结果过了一段时间集群更差了也不知道。调优本质是假设验证，改任何一个参数之前，先记录当时的基线：写延迟P99、读延迟P99、GC频率、HFile数量。调整后等待至少半天到一天，再对比这些数据，确认是变好了还是变差了。

如果数据表明没变化，就果断回滚。不要因为“这个参数在网上都说应该这么调”就死扛。每个集群的负载模式、硬件条件、表结构都不一样，只有数据会说真话。

5. 一次写延迟毛刺的完整排查复盘：从指标异常到根因落地

5.1 现象和第一反应

说一个模拟项目里的真实复盘，集群规模是16台RegionServer，业务主要是写入密集的日志类数据。有一天下午，监控告警突然报“写延迟P99超过预警线”，平均写延迟从8毫秒涨到300毫秒以上。这个量级的变化，已经不只是“毛刺”了。

我当时的排查习惯是：不先怀疑HBase本身，按照OS、JVM、HBase、HDFS四层逐个排除。

5.2 逐层排查链路

先看OS层。CPU整体利用率只有30%左右，看起来很正常。但进一步看磁盘，发现有两台数据节点的await已经在100毫秒上下波动，其余节点都在20毫秒以内。这里有个初步嫌疑：问题可能出在存储局部，而不是全局过载。

再看JVM层。打开GC日志，发现Full GC平均每8分钟一次，单次停顿3到5秒。这个频率和停顿时间已经非常高了。再看堆使用，老年代在Full GC结束后很快又涨回去，说明堆里长期有大量存活对象被反复晋升。

然后看HBase层。Memstore占比已经到80%以上，Flush队列积压明显。某个RegionServer上的Region数量在一个小时内从300涨到了接近700，里面有大量Region正在经历分裂。与此同时，每个Store的HFile数量从平均6个涨到了30个以上，Compaction明显在疲于奔命。

最后回到HDFS层。前面发现的磁盘异常节点，都集中在一个机架上。查了数据分布后发现，最近几天分裂产生的新Region，很多都分配到了这几台机器上，数据本地化变差，读写都开始跨网络，进一步放大了延迟。

5.3 根因结论

问题根因是RowKey设计变更导致的连环反应。业务方上线了新逻辑，RowKey改成以时间戳为前缀，写入自然高度集中到“当前时间”这个Region上。新Region被写满后频繁分裂，Region数量暴增，分裂和迁移导致数据本地化变差；同时Memstore被不断增长的写请求打满，触发Flush和Compaction风暴，GC频率上升，最终表现为写延迟雪崩。

这个案例里没有任何一个指标单独看起来“致命”，但多层指标互相印证后，问题链条就很清晰了。

5.4 处理动作和效果

处理分了几个阶段：

• 紧急恢复阶段：先暂停了低频的预写任务（非核心业务），把写入压力降下来，让Flush和Compaction能喘口气。
• 根因处理阶段：把这个表和业务方一起重新设计RowKey，改成“用户ID取模前缀+时间戳”的形式，同时按新的RowKey做预分区，让写入均匀分散到所有RegionServer上。
• 参数优化阶段：调大Compaction线程数，同时把major compaction安排到每天凌晨低峰期。
• 落地验证阶段：两周后，写延迟P99回落到15毫秒以内，Full GC从每8分钟一次降到每天一两次，HFile数量稳定在个位数。

复盘时最大的感受是：监控的价值不在“发现故障”，而在“缩短从故障现象到根因的距离”。如果没有分层监控和足够长的历史曲线，这个案例大概率会演变成“重启大法”或者“疯狂调参数盲试”。

6. 监控图表之外的各种隐性坑

6.1 只看平均值，P99被平均吃掉了

很多自带的监控面板默认展示平均值，这其实是一个很大的误导。平均写入延迟50毫秒，听起来还行，但可能意味着一大半请求只要10毫秒，而有5%的请求已经超过了500毫秒。读了下监控去打业务侧问，才发现用户感受到的卡顿已经很明显了。自建监控一定要把P99、P95作为默认展示维度，尤其是延迟类指标。

6.2 只监控HBase，不考虑底层文件系统状态

HBase跑在通用的存储系统之上，它的健康度跟底层存储的健康度强相关。比如磁盘出现慢盘、RAID重建、网络交换机端口异常，这些在HBase指标上不会直接体现，但最终都会表现为IO耗时上升。所以监控一定至少要覆盖“写路径依赖的底层设备”，否则排查时永远缺一块拼图。

6.3 扫表请求被当成正常读请求

HBase的读请求里，大范围扫描和单行Get完全是两回事。一次不带有效过滤条件的全表扫描，产生的服务器压力可能相当于几百次Get，但监控上的“读请求数”只增加一次。如果只统计请求次数，不看扫描返回的数据量，会被数据欺骗。我发现需要为扫描类的查询单独设置记录或者排查机制，避免某些低频高资源请求把集群打垮。

6.4 分裂和均衡过程中忽略过渡状态

Region的分裂、迁移、下线、上线都有中间状态，这些状态期间对应的Region是暂时不可用的。监控通常不会把“Region处于过渡状态”作为重点展示，但如果过渡状态的Region数量一多，业务侧就会出现随机超时和重试。我习惯盯一下RegionServer UI上的过渡Region计数，一旦在非维护时段出现持续不为0的情况，就要警惕。

6.5 告警疲劳是真实存在的

最后一点可能更像管理问题，但技术上也值得讨论。监控系统如果一天到晚乱报，告警就会被值班同事直接无视，真正的严重故障反而没人响应。所以我一直强调：告警宁可少而精，不要多而滥。凡是“报了也没法处理”的告警，不如不报。把指标分层、阈值做准、加持续时间过滤，比单纯恨不得把所有指标都挂上告警要好得多。

我自己的习惯是，每个月把告警记录翻一遍，凡是连续两周没有触发过、或者触发后不需要任何动作的规则，就直接删掉或者降级。一套监控体系要持续维护才能保持战斗力，它不是配好了就完事的一次性工程。