企业官网建设流程全解析

管理过HBase集群的同学应该都有过这种经历：集群规模一旦上来，HBase自带的Web Console就像隔着一层毛玻璃看机房——单台RegionServer的内存、请求、Compaction状态倒是能看到，但整个集群几十台机器的横向对比、历史趋势回溯、阈值告警，基本属于半瘫痪状态。尤其是业务高峰期，线上反馈写入变慢，你打开HBase页面挨个节点翻半天，才隐约觉得哪台机器MemStore有点不太对劲，这种排查效率放在生产环境里确实难受。

Grafana加Prometheus的组合，就是解决这套问题的标准答案。我前前后后在好几个集群上搭过HBase监控面板，从最早的JMX裸奔抓取，到后面用JMX Exporter统一暴露指标，再到Grafana看板层层钻取，整个过程踩了不少坑，也总结出了一套相对成熟的做法。这篇文章把整套可视化监控面板的配置思路、实操细节、坑点排错完整写出来，适合正在为HBase集群监控发愁的运维同学，也适合想把现有看板做得更专业的平台工程师参考。

1. 整体方案与技术选型

1.1 为什么不直接看HBase自带页面

先把自带监控的真实短板说清楚。HBase Web UI确实能看每个进程的JVM堆、Region数量、请求延迟、队列长度这些核心项，但它的问题也很致命：单进程视角，想看集群整体得一台一台点；没有持久化存储，页面刷新历史数据就没了，想复盘昨天下午的Full GC根本无从下手；告警能力几乎为零，总不能靠人工盯着屏幕。所以生产集群基本都要外接一套监控系统。

在选型上，当前主流就是Prometheus加Grafana，没有之一。我早期也试过用脚本定时抓JMX数据入库然后画图，虽然能用，但脚本的健壮性、数据粒度、面板交互都差一个量级。Prometheus本身只负责抓取和存储时序数据，Grafana负责把数据可视化成看板，两者配合几乎成了大数据组件监控的默认组合。

Grafana另一大优势是生态成熟，社区里HBase、HDFS的现成Dashboard模板一抓一大把，导入之后稍微改改指标名就能直接落地。对比自研或者用HBase自带的监控，时间成本完全不在一个量级。

1.2 数据链路与核心组件

整个链路不复杂，数据从HBase进程出来，最终落到Grafana面板上，中间经过三个环节：

1. HBase的Master和RegionServer进程启动时挂载JMX Exporter的javaagent，通过配置好的HTTP端口暴露监控指标。
2. Prometheus按配置的抓取周期，轮询这些HTTP端口，把指标存进自己的时序数据库，形成带时间维度的历史数据。
3. Grafana把Prometheus作为数据源，通过PromQL查询语句把指标动态渲染成折线图、热力图、状态面板。

我画个更直白的类比：HBase进程相当于一个人做体检，JMX是体检报告，JMX Exporter是把报告翻译成机器能读的标准格式贴到公告栏，Prometheus是每天定时抄录公告栏的人，Grafana则是把抄下来的数据做成可视化仪表盘的展示台。任何一个环节断了，面板都会出问题，后面排查部分我会逐个讲。

选型时有个细节值得多说一句：接入Prometheus有两条路，一条是直接暴露JMX RMI端口，让独立的jmx_exporter进程去连；另一条是给JVM挂javaagent，直接在进程内把JMX指标转成Prometheus格式的HTTP接口。实际生产我强烈建议选javaagent方案，因为JMX RMI端口经常因为RMI动态端口、hostname回环问题导致Prometheus抓不到，javaagent简单粗暴，一个端口直接完事，后面问题排查一节我会讲具体案例。

2. 监控指标梳理与面板规划

2.1 HBase监控到底要看什么

HBase的监控维度比一般业务服务复杂，因为它有Master和RegionServer两类进程，还重度依赖HDFS做底层存储。我习惯把指标分成四层来看：

第一层是进程健康度，也就是Master和RegionServer各自的JVM情况。堆内存使用、GC次数和耗时、线程数这些基础项，往往能第一时间暴露Full GC导致的服务抖动。

第二层是RegionServer的读写吞吐，核心是Read Request Count和Write Request Count，以及配套的延迟指标。注意延迟指标有很多种，光看均值没意义，生产上重点关注p99/p999，或者看Blocked Update Time——写入被阻塞的时间，这个指标一旦飙升，基本就是MemStore刷写跟不上节奏了。

第三层是存储引擎的实时状态，包括MemStore大小、StoreFile数量、BlockCache命中率、Region数量、Compaction队列和Flush队列长度。这一层直接对应HBase内部是否有积压，像Compaction队列长度异常拉长，其实就是资源快耗尽的前兆。

第四层是底层依赖，也就是HDFS的空间使用率、DataNode读写状态、文件块分布。HBase的RegionServer再稳定，底层HDFS磁盘满了，一切白搭。所以做HBase监控时顺手把HDFS的关键项也拉进来，能省掉很多排查环节。

2.2 三个层级的看板设计原则

Grafana面板不是指标堆得越多越好，堆一堆折线只会让人看得脑子发涨。我自己实践下来，一套合格的HBase监控看板应该分成三个层级：

整体总览层：整个集群一个页面搞定的那种。核心放2到4个Stat面板，分别显示在线RegionServer数量、集群总Region数、整体读/写请求速率、HDFS剩余空间；下面放一组时间序列，画出集群请求量趋势、P99延迟趋势、平均Compaction队列长度。这个页面给值班和应急人员扫一眼用。

单节点钻取层：通过Grafana的模板变量，把节点hostname做成下拉框，选一台RegionServer之后，页面上所有面板都跟着切换。展示这台节点的读/写延迟、堆内存、MemStore、StoreFile、BlockCache、GC情况。线上出现单节点热点时，这个页面就是战斗主阵地。

内部细节层：专门放Compaction、Split、Flush这几个低频但破坏性强的操作。比如Compaction的输入输出量、执行耗时、队列积压，Flush的时间分布，Region Split的触发次数。平时不怎么盯，但出问题时全靠它定位。

2.3 指标名的头号大坑

先给大家打个预防针：JMX Exporter暴露出来的指标名，跟你从HBase源码里看的Metrics名字不是一比一对应的，而且不同版本的HBase加上不同的Exporter配置，最终落到Prometheus里的指标名都可能不一样。

比如HBase的Read Request Count，在源码Metrics里叫readRequestCount，但在Prometheus里很可能变成hbase_regionserver_requests_total这种带_total后缀的指标，再加上一堆label来区分read/write。我见过最坑的情况是某个版本直接把指标暴露成了hadoop_metrics_hbase_xxxx这种前缀，让人完全摸不着头脑。

所以无论看多少教程，实际动手的第一步永远是：先把Exporter关掉配置跑起来，在Prometheus的查询页面里搜hbase，把实际存在的指标名列出来，对照着自己要画的指标项一个个找。这一步虽然笨，但比照着网上的Dashboard模板瞎猜指标名靠谱得多。

3. 实操：从零搭建监控面板

3.1 环境准备与JMX Exporter接入

准备一套干净的方案只需要四个组件：HBase集群（我是以2.x版本为例）、Prometheus、Grafana、JMX Exporter的javaagent jar包。以一台Master加两台RegionServer的最小集群做示范，注意Master和RegionServer的Exporter端口必须分开。

先把jar包放到每台HBase节点的固定目录，比如/opt/jmx_exporter/下，然后修改hbase-env.sh，追加JVM参数：

# hbase-env.sh 追加内容 export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS -javaagent:/opt/jmx_exporter/jmx_prometheus_javaagent-0.20.0.jar=9505:/opt/jmx_exporter/hbase_master_config.yaml" export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS -javaagent:/opt/jmx_exporter/jmx_prometheus_javaagent-0.20.0.jar=9510:/opt/jmx_exporter/hbase_regionserver_config.yaml"

端口这里要专门说一句，Master统一用9505，所有RegionServer统一用9510，不要各搞各的端口，否则后面Prometheus配置会写到你怀疑人生。yaml配置文件建议先从最简配置起步：

# hbase_master_config.yaml lowercaseOutputName: true lowercaseOutputLabelNames: true rules: - pattern: 'Hadoop:service=HBase,name=Master,sub=.*'

这个配置的意思是只抓Master命名空间下的指标，RegionServer的配置文件把name换成RegionServer就行。配置完成后重启HBase集群，用curl验证一下端口是否出数据：

curl http://localhost:9505/metrics | head -n 20 curl http://localhost:9510/metrics | head -n 20

看到以# HELP和# TYPE开头，后面跟着一堆以hbase开头的指标文本，说明Exporter已经挂载成功。这里有个经验：验证最好在重启完立刻做，别急着一股脑改完Prometheus再回头看，先确认端口通、指标有，后面才能省心。

3.2 Prometheus采集配置

Prometheus安装本身不啰嗦，下载解压改配置启动就完事。重点是scrape_configs怎么写。我给出一个生产环境可用的最小配置：

# prometheus.yml global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: 'hbase-master' static_configs: - targets: ['master-01:9505'] labels: cluster: 'prod-hbase' role: 'master' - job_name: 'hbase-regionserver' static_configs: - targets: - 'rs-01:9510' - 'rs-02:9510' labels: cluster: 'prod-hbase' role: 'regionserver'

有两个细节值得展开。第一个是scrape_interval，15秒是监控HBase比较合理的默认值，太密了Prometheus存储压力大，太疏了Compaction队列这种快速变化的值会失真。第二个是labels，我习惯加上cluster和role这两个静态标签，因为一个Prometheus很可能同时监控多套HBase集群或者同时监控Master和RegionServer，有了标签，Grafana面板里就能用cluster作筛选，一套看板管多套集群。

配置好以后启动Prometheus，在浏览器访问9090端口的自带的Targets页面确认，两个job都是UP状态。如果是DOWN，优先检查端口和网络，常见的是云主机安全组只开了公共端口没放行9505/9510，这种基础问题能卡一下午。

3.3 Grafana数据源与告警配置

Grafana安装完成后，第一步是添加数据源，Type选择Prometheus，URL填Prometheus的地址和端口，保存并测试。这里有个很不起眼但特别重要的细节：URL千万别写成localhost，因为Grafana和Prometheus很可能不在同一台机器上，就算在，也要用能被其他机器访问的地址，否则后面告警都会从localhost找Prometheus，找不到就全挂。

数据源配置好以后，需要为看板创建模板变量。在Dashboard的设置里添加一个变量，名字叫node，类型选Query，查询语句填Prometheus里的节点标签，类似这样：

label_values(hbase_regionserver_requests_total, instance)

这样面板顶部就会多一个下拉框，可以在多台RegionServer之间切换。这个变量建好以后，后续所有单节点面板的查询语句里都可以引用$node，Grafana会自动转换成当前选中的节点。

告警配置同样在这个阶段完成。Grafana的告警规则是基于面板查询来配的，比如写一条RegionServer堆内存超过85%的告警：

max_over_time(jvm_memory_bytes_used{job="hbase-regionserver"}[10m]) / max_over_time(jvm_memory_bytes_max{job="hbase-regionserver"}[10m]) * 100 > 85

这里用到max_over_time是为了避免瞬时抖动造成的误报，让连续10分钟都超过阈值才触发，实际使用下来误报率会低很多。告警通知渠道按你团队的习惯配就行，邮件、企业微信群机器人或者Webhook都支持，关键是测试告警一定要真实触发一次，确认消息能收到，别等到线上真正出事才发现告警通道是坏的。

3.4 从零手写一个核心看板

导入现成模板省事，但自己手写一次看板，能让你对整个指标体系和查询逻辑理解得更透。我以最常见的“RegionServer请求量和延迟”面板为例，走一遍完整流程。

新建一个Dashboard，添加一个Time series面板，标题叫“集群读请求速率”，Query编辑器里输入：

sum(rate(hbase_regionserver_read_requests_total{cluster="prod-hbase"}[5m]))

再添加一个面板写写入速率，把上面的read换成write。如果你用的指标名不是hbase_regionserver_read_requests_total，先回到Prometheus查询页面找到真实的指标名替换即可。

延迟类指标更讲究一些。HBase的延迟很多是带分位数的，比如get的p99。这种指标通常会用histogram_quantile来计算：

histogram_quantile(0.99, sum(rate(hbase_regionserver_get_latency_seconds_bucket[5m])) by (le, instance))

这段查询的意思是，统计近5分钟内所有请求的延迟分布，然后算出99分位数值。画出来的曲线如果是一条平滑的缓坡，说明集群稳定；一旦出现锯齿状的大起大落，说明延迟并不稳定，大概率是有GC或者Compaction在捣乱。

Storage相关面板同样重要，MemStore大小属于Gauge类型，直接用：

sum(hbase_regionserver_memstore_size_mb{cluster="prod-hbase"}) by (instance)

这个面板的意义在于观察全局的MemStore堆积情况，如果某个节点曲线持续走高不回落，说明它的刷写进程可能卡住了，这时候配上Flush队列长度的面板一起看，诊断效率会高很多。

4. 常见问题与排查技巧实录

4.1 JMX Exporter相关的故障

Exporter挂了或者指标抓不到，是搭建过程中最常遇到的一类问题。我按概率从高到低把坑列一遍。

端口不通是第一大坑。有些云环境的机器只放行了常用端口，9505和9510没进安全组，Prometheus一直显示DOWN。排查起来不复杂：在Prometheus那台机器上telnet一下端口，通不通一目了然。另外HBase节点自身的防火墙也可能拦，测试的时候可以先临时放行，确认通了再收窄规则。

第二大坑是JVM参数没生效。javaagent的配置写进hbase-env.sh以后，真正生效的是HBase进程启动那一刻，如果你只重启了RegionServer没重启Master，那Master那边还是旧的JVM参数，端口当然起不来。验证方法是在HBase节点上看进程命令行：

ps -ef | grep java | grep javaagent

参数在输出里就说明挂载成功，不在就是没生效。这个命令建议成为改完配置后的固定动作。

第三类坑比较隐蔽，Javaagent和旧版JMX RMI配置同时存在时，会把RMI端口信息也通过Exporter暴露出来，导致Prometheus抓到的指标里混入大量非HBase类的JVM指标，面板看起来杂乱无章。解决办法就是hbase-env.sh里把原来的JMX RMI参数清理干净，只保留javaagent。

4.2 Prometheus采集中断的处理思路

采集中断的典型表现是：Grafana面板上曲线突然出现大段空白，Prometheus的Targets页面显示UP，但点开看Error字段有内容。常见的有两类错误，一类是HTTP 5xx，说明Exporter端口还在但内部异常，通常重启HBase进程能恢复；另一类是context deadline exceeded，也就是抓取超时。

抓取超时的原因往往是HBase进程本身压力太大，JVM忙于GC，连暴露指标的HTTP接口都响应不过来。遇到这种情况，先把scrape_interval调大试试，比如从15秒调到30秒，让抓取频率降下来。如果还超时，说明HBase问题比较大，得回过去查GC日志和线程栈了。注意别在集群压力大的时候频繁调Prometheus的抓取频率，那是治标不治本，缓解了一时但把真正的问题掩盖了。

4.3 Grafana面板全是空数据的元凶

面板加载出来但线是空白的，是最打击搭建积极性的问题。我的排查路径是固定的：

先看Prometheus查询页面，手动输入面板里那条PromQL，点Execute看有没有数据返回。如果Prometheus里本身是“No data found”，说明指标名不对或者标签筛选条件太严格，去掉cluster、instance这些标签再试，用最宽松的查询找到数据，再一步步收紧标签。

如果Prometheus里有数据但Grafana面板空白，多半是时间范围或者变量的问题。时间范围拉得太小比如只选了最近5分钟，碰巧业务处于低峰请求量为0，曲线就是平的；模板变量$node的值如果传了空字符串，查询条件就变成了一个不存在的instance，自然没数据。这类问题在查询语句里把变量替换成具体值验证一遍就能定位。

还有一个容易被忽略的：Prometheus和Grafana所在机器的时区不一致，导致查询的起始时间晚于数据的最新时间，面板同样会空白。统一两台机器的时区或者直接用UTC，能省掉很多莫名其妙的排查。

4.4 大促场景下的监控经验

最后分享一个压箱底的经验。大促或者业务高峰前，我会在原有告警阈值基础上再预置一套应急看板，专门盯Compaction队列、Flush队列、BlockCache命中率和各个分位数延迟，而不是等到延迟报警了才开始看。这几个指标属于“先行指标”，队列一旦开始积压，后续必然传导到读写延迟上，提前看到积压趋势，就能在业务感知到抖动前介入，给RegionServer扩容或者手动触发一次Major Compaction，尽量避开高峰。

另外有个建议：Prometheus的本地存储保留期默认只有15天，生产环境至少把它调到30天以上。因为排障的时候经常要看一周前的历史曲线来复盘当时的集群状态，数据不够就尴尬了。启动参数加一行--storage.tsdb.retention.time=30d就能搞定，属于一次性配置长期受益的事。

我搭建这套监控面板时，最深的体会就是不要急于把所有指标塞到一个页面上，而是先想清楚三种角色各需要看什么：值班的人看总览，排查的人看单节点，深度分析的人看内部细节。按这个思路分层设计面板，最后用起来的顺手程度会远超一屏塞满三十条曲线的大杂烩。希望这套方案能帮你省掉一些本来会白白搭进去的排查时间。