干过 HBase 运维的人都懂一个道理这套分布式系统写起来容易真正难的是它在跑起来之后你心里有没有底。线上 RegionServer 半夜被 ZooKeeper 踢掉、某个节点 GC 停顿把读写瞬间打爆、看似正常的集群突然积压了几千条 RPC 排队请求……这些场景听得太多。要说“HBase 监控与调优”我的经验是别第一时间去装监控工具先把“关键指标”吃透再决定怎么采、怎么展示、怎么报警。这篇文章就把我在生产环境里反复摸过的一套东西整理出来从监控思路、核心指标到工具选型和指标驱动的调优手段一次讲透。这篇内容适合两类人刚接触 HBase 的开发者想搞明白集群到底该盯哪些数以及已经有集群在跑、正被各种报警和性能问题折磨的运维同学。我会尽量用实际案例来说明避免教科书式念指标定义。按我自己的习惯先聊监控的分层思路再逐项拆关键指标然后给工具选型建议最后用调优场景把指标和操作串起来。1. 监控之前先搞明白的事分层思维1.1 HBase 不是单机是一条依赖链很多新手监控 HBase 的时候眼睛只盯着 RegionServer 进程是不是活着、UI 能不能打开。但生产环境里 RegionServer 的存活高度依赖它底下的 HDFS、旁边的 ZooKeeper、以及自身的 JVM 健康状况。RegionServer 之所以“挂掉”很多时候不是进程退出而是 Full GC 时间太长导致 ZooKeeper 会话超时被集群主动踢出去的。所以监控 HBase 的第一课是把整个依赖链画出来。我一般把监控分成五层硬件与系统层CPU、内存、磁盘 IO、网卡流量、文件句柄数JVM 层堆内存使用、GC 频率、GC 耗时、线程状态HBase 进程层RegionServer 和 Master 的 RPC 处理能力、队列堆积、MemStore 大小、BlockCache 命中率HDFS 层DataNode 健康、HDFS 写入延迟、NameNode 的 GC 状况业务与客户端层读写延迟分位数、失败请求数、重试次数每一层都可能成为瓶颈。比如系统层磁盘 IO 被打满RegionServer 的 WAL 同步就会超时HDFS 的 NameNode 在做 Full GC 时所有 RegionServer 的 flush 都会卡住客户端连接的线程数太多也可能直接把 RPC handler 占满。只看某一个层面很容易误判。1.2 指标不是越多越好报警要分级我见过不少团队把几百个指标全部接到监控系统里每个指标都配了报警规则结果线上真正出事的时候报警被刷屏刷到没人看最后反而漏了关键故障。这属于典型监控过度。HBase 的关键指标我后面会详细展开但先给一个原则报警数据源要少而精指标要能反映“用户感受到的问题”。我会把报警分成三级一级告警RegionServer 进程挂掉、Master 主备切换失败、HDFS 副本数不足、写阻塞持续超过几十秒这些必须立刻响二级告警GC 长停顿出现、RPC 队列开始堆积、BlockCache 命中率持续下跌、Meta 表 region 异常这些要在几分钟内处理三级告警磁盘使用率上升、HDFS 小文件数增多、Region 数量偏离合理区间这是日常巡检或日报里关注的趋势项阈值怎么定不要凭空拍。我的做法是先观察两周的基线数据取正常时期的 p95 值和 p99 值再往上留一点余量。比如平时 GC 停顿时间大概在 100ms 以内那么超过 1s 就可以作为二级告警阈值。这个做法比官方文档给任何固定数字都更贴合你的集群。1.3 监控体系的基本构成别忽略告警闭环一个完整的 HBase 监控体系由采集、存储、展示、告警、处理五部分组成。采集决定你能不能拿到数据存储决定数据能留多久展示决定人能不能看懂告警决定你什么时候知道出事了处理决定问题是否闭环。很多团队只做到前三步数据面板很好看就是没有告警规则或者告警了没人在意。这是监控体系里最可惜的部分。我建议每一条告警都要对应一个明确的处理 playbook这个告警出现时第一步看什么日志、第二步查什么命令、什么时候需要升级处理。后面第 5 节我会专门整理常见问题的排查路径。2. HBase 关键监控指标拆解每个阈值都有出处2.1 RegionServer 请求路径RPC 队列、handler 与排队延迟RegionServer 提供读写服务时核心的观察入口是它的 RPC 处理能力。HBase 对每个 RegionServer 会有若干 RPC handler 线程默认数量根据版本和内存不同通常在 30 到 60 之间。一个请求进来如果 handler 有空闲就直接处理没空闲就放进 RPC 队列排队。你在 RegionServer 的 Web UI 上能看到Queue size、Num running RPC server threads这些信息。如果Queue size持续大于 0说明 handler 不够用请求开始堆积。更精确的指标是 RPC 排队时间也就是一个请求从进入到被处理之间等待的时长。排队时间一旦超过几十毫秒甚至上百毫秒客户端那边就能明显感受到延迟抬升。这里有一个常见误判看到 Queue 高就认为需要调大hbase.regionserver.handler.count。实际上 handler 线程也不是越多越好线程太多会带来上下文切换反而降低吞吐。我做过一次对比64 个 handler 比 30 个 handler 在相同并发下吞吐提升有限但 CPU 核数不够时延迟会明显上升。所以看到 RPC 队列堆积先要判断是“请求量太大”还是“单请求处理太慢”。前者可以加节点分担后者要检查是否存在大 scan、大 value、热点 region、GC 停顿等问题。2.2 内存三兄弟MemStore、BlockCache 和堆内存HBase 的内存管理核心是 RegionServer 堆内存的分区一部分给 MemStore 用来承接写入一部分给 BlockCache 用来缓存读到的 HFile 数据块剩下的是 JVM 自己跑代码的空间。三者比例失衡一定会出问题。MemStore 大小是写路径最直接的观察对象。每个 Region 有一个 MemStore当它大小超过hbase.hregion.memstore.flush.size默认 128MB时会触发 flush 把内存数据写成 HFile。整个 RegionServer 的 MemStore 总量占堆内存比例超过hbase.regionserver.global.memstore.size默认约 0.4时会触发强制 flush如果此时仍有大量写入进来最终会进入写阻塞状态。所以监控要盯两个点单 Region 的 MemStore 大小和整台 RS 的 MemStore 总占比。BlockCache 命中率是读路径的核心指标。命中率越高说明读请求越能从内存缓存拿到数据不用落到磁盘扫 HFile。L1 命中率通常在 90% 以上才比较健康L2如果用 BucketCache CPU 类方式要自己定基线。如果命中率长期在 70% 以下先查缓存空间是不是被 MemStore 挤占了再查业务读模式是否包含大量全表扫描——scan 通常会直接穿透缓存把 LRU 淘汰得七零八落。GC 指标是内存状况的直接投影。我每次看一个 RegionServer 状态必看两点Full GC 次数和单次 GC 停顿时间。如果 Full GC 频率超过半小时一次或者单次停顿超过 1 秒这个节点基本已经处于“半死”状态读写的抖动会很随机。2.3 存储与 CompactionStoreFile 数量、Compaction 队列、WAL 状态Region 内的数据最终以 HFile 的形式存在 HDFS 上。每做一次 flush就会产生一个新的 HFile。HFile 越多读请求要合并的文件数量越多性能越差。于是 HBase 后台会做 compaction 把小文件合并成大文件。你要盯住的指标首先是单个 Store 下的 StoreFile 数量。正常情况下稳定运行的 RegionStoreFile 数量在几个到十几个之间波动。如果一直涨说明 MemStore flush 太快或者 Minor Compaction 跟不上文件产生速度。其次是 Compaction 队列长度这个在 RegionServer UI 的Compaction Queue那栏能看到。队列长时间不为 0说明后台 compaction 已经积压了。WALWrite-Ahead Log是 HBase 写数据先落日志、再进内存的关键机制。WAL 同步到 HDFS 的耗时直接决定写延迟。如果 WAL 同步时间经常超过 100ms大概率是 HDFS 写入慢或者磁盘 IO 问题。另一个要关注的是 WAL 文件数量RegionServer 宕机后 WAL 需要被重放WAL 文件多、体积大恢复过程就会特别慢。2.4 Region 分布与热点数量、分裂与请求倾斜Region 是 HBase 数据分布和负载均衡的最小单元。一台 RegionServer 上承载的 Region 数量过多会导致每个 Region 的平均资源变少请求容易互相争抢过少又可能导致某些 RS 空闲。生产上一般控制在几十到一两百个 Region 每台具体取决于请求量和数据规模。除了数量还要看区域分布。我遇到过一种很典型的故障某个表的 rowkey 设计成时间戳前缀结果所有写入都落在同一个 Region 上这台 RS 的负载飙升到其他节点的十倍其他机器闲置。监控层面要盯每个 Region 的请求量而不是只看整台 RS 的平均值。看单个 Region 的 readRequestCount 和 writeRequestCount把数值明显高于平均值的区域挑出来看是否是热点。Region 分裂和合并状态同样要监控。HBase 的 Region Split 会短暂阻塞该 Region 的写入如果集群频繁进行大量分裂操作会引起写毛刺。Master 的 UI 上能看到Region In Transition的信息。如果 RIT 长时间卡在某个状态比如 OPENING 或 CLOSING 一直不结束说明 region 的迁移出了问题需要及时介入。2.5 客户端体验延迟分位数与失败量所有集群层面指标最终都要落到客户端感受上。很多人只看吞吐量每秒请求数但吞吐高不代表体验好。高吞吐 高延迟是完全可能同时出现的。所以我会把读延迟和写延迟的 p99 值作为核心告警项。客户端 HBase 的监控可以分成两种方式在应用侧埋点统计比如用 HBase 客户端自带的 Metrics 或者自己封装一层记录每次 get/put/scan 的耗时另一种是看 RegionServer 上按 Region/表维度统计的延迟。应用侧埋点有一个好处它能直接反映用户真实体验并且能区分是网络问题、服务端问题还是客户端 GC 问题。我在生产环境还会顺带统计重试次数比如 Region 发生 split、region 迁移或 RS 宕机时客户端会有重试。重试次数突然变多通常意味着集群内部不稳定。3. 监控工具怎么选从自带 UI 到 Prometheus 全家桶3.1 HBase 自带 Web UI应急排查第一站HBase 自带一套基于 Web 的监控页面。Master UI 默认端口是 16010RegionServer UI 默认是 16030。Master 页面会列出所有 RegionServer 的状态、请求数、Heap 使用、Region 数量这些信息。点进单个 RegionServer你能看到更细的指标MemStore 大小、StoreFile 数量、BlockCache 命中率、Compaction 队列等。这是排查问题时最快捷的入口。自带 UI 的缺点很明显它没有历史趋势只有当前快照。你只能在“正在出问题”的时候打开它看现状出完问题之后只能靠截图回忆。另外它也没有告警能力不可能 7×24 小时盯着页面看。所以自带 UI 适合作为排查工具不适合作为监控方案。3.2 老牌方案 Ganglia部署简单但灵活度有限Ganglia 是很多早期 HBase 集群选择的监控系统HBase 原生支持把 Metrics 输出到 Ganglia只需要在hbase-site.xml里配置hbase.metrics相关参数。部署不复杂能画曲线图对当时的运维场景够用。但它的问题在于配置繁琐、告警能力弱、图表交互差而且很多团队对 Ganglia 的维护能力不足最后变成了一个只收集不看的“数据坟墓”。如果你还在用老版本 CDH/HDP 的 HBase 集群可能会碰到 Ganglia 或者类似机制。新集群我一般不推荐从零部署 Ganglia。3.3 现代主流方案Prometheus Grafana JMX Exporter现在做 HBase 监控我最推荐的是 Prometheus Grafana 这套组合。HBase 本身基于 Java几乎所有运行指标都能通过 JMXJava Management Extensions暴露出来。社区里有现成的jmx_prometheus_javaagent可以在启动 RegionServer 或 Master 时通过 javaagent 的方式把 JMX 指标转成 Prometheus 格式然后让 Prometheus 定期抓取。具体操作思路是在hbase-env.sh里给HBASE_MASTER_OPTS和HBASE_REGIONSERVER_OPTS加上类似这样的参数-HBASE_MASTER_OPTS$HBASE_MASTER_OPTS -javaagent:/opt/jmx_exporter/jmx_prometheus_javaagent.jar9404:/opt/jmx_exporter/hbase_config.yaml -HBASE_REGIONSERVER_OPTS$HBASE_REGIONSERVER_OPTS -javaagent:/opt/jmx_exporter/jmx_prometheus_javaagent.jar9410:/opt/jmx_exporter/hbase_config.yaml然后为每一个 RegionServer 配置 Prometheus 的scrape_configs抓取任务用 Grafana 导入现成的 HBase Dashboard社区有多个模板导入后按你的指标名微调即可。这套方案的优势是生态完整、告警灵活、图表美观。Prometheus 的 Alertmanager 可以按规则将告警推送到钉钉、邮件或企业微信扩展很方便。缺点是需要额外维护一套组件对于只有一两台 RegionServer 的小集群来说有点重。3.4 hbase top 与商业化监控容易忽略的补充其实 HBase 自带的hbase top命令是非常好用的命令行监控工具。它类似 Linux 的 top按照 RegionServer 维度实时展示读写请求数、延迟等指标还能按表、按 Region 维度排序。排查某个 Region 是不是热点时hbase top比打开 UI 翻好几页更高效。比如执行后可以看writeRequestCount最高的 Region判断数据倾斜。每次上线新表或者排查线上热点我都会先跑一下这个命令。另外如果你使用的是商业发行版集群比如 CDH 或 HDP它们的控制台里其实已经集成了完整的 HBase 监控面板和告警。直接在这些平台里查看指标、配置阈值是最省事的方式。代价是平台本身有一定授权和维护成本但很多公司并不需要自己再去搭一套 Prometheus。下面把工具选型做个简单对比方案历史数据告警能力部署成本适用场景HBase 自带 UI无无零临时排查、快速定位Ganglia有弱中老集群兼容Prometheus Grafana有强中高主流生产环境推荐hbase top无无零命令行实时查看热点Cloudera Manager / Ambari有中平台自带使用商业发行版的公司4. 指标驱动调优从报警到动手改配置4.1 写路径调优MemStore 频繁 flush 与写阻塞写阻塞是 HBase 生产环境里最严重的故障之一现象是客户端写入延迟飙升、写入抛RegionTooBusyException或DoNotRetryIOException。背后的链路通常是这样的单 Region 的 MemStore 超过 flush 阈值、整台 RS 的 MemStore 总占比超过全局限制HBase 触发强制 flush但写入速度远高于 flush 速度最终memstore分配不出新空间所有写入暂停。我在一次调优中就遇到类似情况。业务侧凌晨批量导入数据写入量是平时的 5 倍RegionServer 日志里出现大量 “memstore is above high water mark” 的提示。先确认两个指标整台 RS 的 MemStore 占比确实超过了 0.4同时单 Region 的 MemStore 大小也频繁超过 128MB。做的调整包括这些方面调大 RS 堆内存给 MemStore 更多绝对空间在确认读缓存压力可控的前提下适当降低hfile.block.cache.size让 MemStore 的占比上限更高批量导入任务切换为 HBase 自带的HFileOutputFormat方式先生成 HFile 再直接 bulk load 进表绕开写路径的内存压力如果单 Region 写入过快检查 rowkey 是否倾斜必要时预分区或加盐但要提醒一句调参不能解决无限增长的写入需求。如果业务写入量长期超过集群设计容量最有效的动作是横向加 RegionServer 节点而不是把内存参数压到极限。4.2 读路径调优BlockCache 命中率低与大 Value 读取读性能差的表现是 get 和 scan 延迟居高不下。打开 RegionServer UI 看 BlockCache 命中率如果长期低于 80%说明大量读请求没有在缓存中命中的每次都在扫磁盘。优化的思路按照“数据访问模式”来定。如果是热点小数据量的 get 请求优先保证 BlockCache 空间把hfile.block.cache.size维持在一个较高的值同时避免 scan 大量污染缓存。如果业务有明显的“冷热分离”可以把热数据单独建表或者配合 HBase 的 MobMedium Object Storage特性把大于一定阈值的大 Value 单独存储避免大对象挤压缓存空间。还有一个被低估的配置是 BloomFilter。在 Get 请求场景下BloomFilter 可以快速判断 HFile 里是否包含目标 key大幅减少无效磁盘 IO。创建表时给列族设置BLOOMFILTER ROW或ROWCOL对读性能提升非常明显。如果线上存量表没有启用 BloomFilter可以动态修改列族属性但要注意修改后需要触发一次 Major Compaction 才能对已有的 HFile 生效。4.3 JVM 与 GC 调优减少长停顿HBase 是典型的大内存 Java 服务JVM 调优直接影响集群稳定性。RegionServer 的堆内存越大GC 压力越大。生产上堆内存通常设置在 16GB 到 64GB 之间但超过 32GB 后常规的 CMS 垃圾回收器会出现比较严重的并发模式失败和长停顿建议使用 G1 垃圾回收器并合理设置目标停顿时间。我一般会在hbase-env.sh里关注这些参数-Xms和-Xmx保持一致避免动态扩容带来的性能损耗-XX:MaxGCPauseMillis设置目标停顿-XX:PrintGCDetails打开 GC 日志然后配合jstat或 Grafana 里的 GC 面板持续观察新老年代的使用情况。GC 日志最好单独输出到固定目录方便出问题时复盘。GC 调优不是一次性的。每次改动 JVM 参数后至少观察一周的 Full GC 频率和停顿分位数。我见过不少人把MaxGCPauseMillis调到很低结果 GC 频率翻倍CPU 被垃圾回收线程吃满吞吐反而下降。停顿和吞吐之间永远有一个平衡点要通过数据找而不是靠直觉定。4.4 Compaction 风暴与 Region 数控制Compaction 是 HBase 后台开销的大头。默认配置下Major Compaction 周期是 7 天如果整个集群所有 Region 同时到达这个时间点后台会集中触发大量 compaction磁盘 IO 和 CPU 瞬间飙升业务读写被拖垮。这就是常说的 compaction 风暴。我的处理手段是把 Major Compaction 错峰执行在hbase-site.xml里把hbase.hregion.majorcompaction设为 0关闭自动 Major Compaction通过定时脚本或者调度平台在业务低峰期手动执行major_compact命令按表或者按 Region 分组执行控制并发监控脚本执行期间的系统 IO 和 compaction 队列长度一次不要同时压太多 Region这里还要注意一个小坑手动执行major_compact如果传的是表名HBase 会把表的所有 Region 一起压缩仍然可能瞬间打满 IO。更稳妥的方式是按照 region 范围分批执行比如每次只 compact 这个表的部分 region。Region 数量控制是另一个日常动作。Region 太多不仅增加 Master 的管理开销也会让 Compaction 变得碎片化。当一个表的数据量增长到一定程度可以考虑批量合并小 Region或者重新设计预分区策略避免无规律分裂。日常巡检时我会关注每台 RS 的 Region 数量是否偏离平均值太多偏差过大说明负载均衡策略执行不及时可以考虑手动执行balancer或排查是否有 Region 卡住无法迁移。5. 常见故障排查实录与避坑清单5.1 RegionServer 异常退出先看 GC 日志和 HDFSRegionServer 进程消失第一反应不是直接重启而是搞清楚为什么消失。因为如果根因不解决重启之后很快还会再挂。常见的套路是按照下面顺序排查打开 RegionServer 日志搜ERROR、FATAL或Aborting如果日志里出现ZooKeeper session closed基本可以判断是与 ZooKeeper 的会话超时需要进一步看 GC 停顿和网络状况查看 GC 日志里最近一次 Full GC 的耗时如果超过 ZooKeeper 会话超时时间默认 30 到 60 秒那就是长停顿导致被踢检查 HDFS 侧的状态DataNode 是否健康、写入是否有大量超时。HDFS 抖动会让 WAL 同步卡住进而导致 RegionServer 整体响应变慢我处理过不止一次所谓的“RegionServer 挂了”最后定位到是 HDFS DataNode 所在的宿主机磁盘故障一个进程退化让整个 RegionServer 写入阻塞最终引发连锁反应。所以遇到 RegionServer 挂不要只盯着 HBase 自己的日志。5.2 磁盘 IO 打满与延迟抖动RegionServer 所在节点磁盘 IO 使用率长期超过 80% 是最容易被忽视的隐患。HBase 的写入最终要落到 HDFS读取在缓存未命中时要扫 HFilecompaction 也在疯狂读写磁盘。磁盘 IO 一旦打满三个动作都会被拖慢。排查磁盘 IO 的工具很简单iostat -x 1看%util和await超过 80% 基本可以确认瓶颈在磁盘侧。这时候要结合 compaction 队列、MemStore flush 情况来判断是哪类 IO 请求在占用。如果是 compaction 高峰期评估是否错峰如果是业务读写本身就有极大的 IO 需求考虑把 Region 数据分散到更多节点或者换用 SSD。有个容易被忽略的细节Snappy 压缩。给 HBase 列族开启数据压缩如COMPRESSION SNAPPY之后落盘的数据量能减少一半以上磁盘 IO 压力明显下降CPU 的压缩解压开销换来 IO 收益在 IO 密集型场景里非常划算。5.3 热点 Region 与数据倾斜处理热点 Region 的典型表现是多台 RegionServer 的负载差距悬殊。我遇到过一个慢查询案例一个表按用户 ID 做 rowkey 前缀但少数头部用户的数据量和 QPS 是普通用户的几百倍那部分请求全部打在那几个固定 Region 上。处理数据倾斜的思路有几个方向针对 rowkey 做加盐或哈希散列让数据分布到不同 Region如果热点 key 是明确的少量用户可以考虑单独建表或把热点数据复制到多个 Region使用 HBase 的 Region 分组功能把热点表限制在特定 RegionServer 组避免影响其他表短期应急时手动 split 热点 Region让请求分散到更多 Region 上缓解单 Region 压力用什么方法取决于业务模式。加盐能缓解整体倾斜但会让按原 key 的范围 scan 失效这点需要跟业务方对齐再实施。5.4 避坑清单日常巡检我必查的几项最后分享一下我在巡检时的固定动作。很多故障在爆发前其实都有预兆只是没有在日常巡检中被注意到。每周至少看一次所有 RegionServer 的 Region 数量分布偏离平均 30% 以上要调查原因观察 Region 的StoreFile数量趋势持续上升说明 compaction 跟不上有变成小文件风暴的风险看一眼 HDFS 的Under-replicated blocks数量。长期不为 0说明副本恢复有问题一旦有节点故障数据丢失风险增大检查物理磁盘剩余空间HBase 的 RegionServer 写满 HDFS 之后会发生特别难排查的奇怪错误比如 region 无法打开翻一下 Master UI 上的Region In Transition确保没有长时间卡住的 region 转移确认服务端的 GC 日志确实在输出而不是日志目录权限有问题导致根本没写出来这些检查每个单独看都不复杂但合起来能帮你建立一套“身体指标”的直觉。做 HBase 时间久了你会发现绝大多数故障都有前兆而监控调优的本质就是把这些前兆变得可观测、可量化、可处理。我自己现在的习惯是每周一早上花十分钟把上一周的监控日报翻一遍重点看 GC 趋势和延迟 p99 有没有缓慢爬升的迹象。很多问题不是突然爆发的而是一点点恶化等到用户开始抱怨的时候往往已经持续坏了好几周。监控如果只是建了个面板当摆设就完全失去了意义。希望这篇整理能让你在搭 HBase 监控和调优时少走一些我踩过的弯路。
