监控 RocketMQ 集群的健康状态是保障业务稳定性的核心环节。业界通常采用自动化监控工具结合多维度指标的方式来构建监控体系。

以下是关于“如何监控”以及“需要关注哪些关键指标”的详细指南：

---

一、 如何监控 RocketMQ 集群？（监控方案与工具）

在实际生产环境中，通常会结合以下几种工具来构建全方位的监控体系：

1. 黄金组合：Prometheus + Grafana + RocketMQ Exporter

这是目前开源社区最主流的方案。

• RocketMQ Exporter：官方提供的指标采集工具。它通过 RocketMQ 的 MQAdmin 工具拉取 Broker 和 NameServer 的运行状态，并暴露为 Prometheus 格式的 Metrics。
• Prometheus：定时从 Exporter 抓取数据并存储。
• Grafana：配置大盘（Dashboard），直观展示 TPS、积压量、延迟等数据。（社区有现成的 RocketMQ Dashboard 模板可以直接导入）。

2. 官方管理控制台：RocketMQ Dashboard (原 RocketMQ Console)

• 定位：轻量级的运维与监控管控台。
• 功能：可以直接查看集群拓扑、Broker 状态、Topic 路由、消费组延迟（Lag）、死信队列，甚至可以直接模拟发送消息和重置消费位点。
• 适用场景：日常排查问题、应急运维干预。

3. 基础资源与 JVM 监控：Node Exporter + JMX Exporter

• Node Exporter：监控部署 RocketMQ 的服务器的 CPU、内存、磁盘 I/O 和网络。
• JMX Exporter / Arthas：因为 RocketMQ 是 Java 编写的，监控 Broker 和 NameServer 的 JVM 状态（堆内存、GC 频率）至关重要。

4. 链路与日志监控：SkyWalking / ELK

• SkyWalking / 各种 APM：追踪消息从 Producer -> Broker -> Consumer 的完整链路，定位是哪个环节耗时过长。
• ELK (Elasticsearch, Logstash, Kibana)：收集 ~/logs/rocketmqlogs/ 下的 broker.log、namesrv.log 等日志，监控 ERROR 级别的异常并报警。

---

二、 需要重点关注的关键监控指标

RocketMQ 的监控指标可以分为四个维度：消息积压与消费维度、Broker 核心指标、基础架构与 JVM 维度、高可用维度。

1. 消息积压与消费维度（最影响业务体验的指标）

这是日常监控的重中之重，直接关系到业务是否正常流转。

• Consumer Lag（消费者积压量 / 延迟量）：
  • 含义：Broker 中未被消费的消息总数（最大位点 - 当前消费位点）。
  • 关注点：当该指标持续上升且不下降时，说明消费能力不足或消费者出现故障（如假死、死锁）。
• Consume TPS（消费吞吐量）：
  • 关注点：消费者的处理速度。如果 TPS 突然掉底（归零），大概率是消费者进程挂了或网络断了。
• DLQ Message Count（死信队列消息数）：
  • 含义：消费者多次重试（默认 16 次）仍失败的消息，会被扔进死信队列（%DLQ%ConsumerGroupName）。
  • 关注点：死信队列有消息，意味着业务处理出现了无法自我恢复的异常（如代码 Bug、脏数据），必须触发高级别告警并人工介入。

2. Broker 核心维度（最影响集群稳定性的指标）

Broker 是 RocketMQ 的心脏，它的健康直接决定了整个集群的生死。

• Broker TPS (Put / Get)：
  • 含义：Broker 接收（Put）和拉取（Get）消息的吞吐量。
  • 关注点：监控整体流量水位，判断是否需要扩容，或者是否遭受了异常流量洪峰。
• Disk Usage（磁盘使用率）：
  • 含义：存储 CommitLog 和 ConsumeQueue 的磁盘空间。
  • 关注点：极其重要！ RocketMQ 默认在磁盘使用率达到 85% 时会限制写入，达到 90% 时会拒绝写入（变为只读）。必须设置阈值告警（如 75% 警告，80% 严重）。
• Message Put Latency（消息写入延迟）：
  • 含义：Producer 将消息写入 Broker 的耗时。
  • 关注点：正常情况下应在几毫秒以内。如果出现大量的几十毫秒甚至上百毫秒，可能是磁盘 IO 达到瓶颈（如发生 PageCache 刷盘慢、或者 JVM GC 停顿）。
• PageCache / 刷盘延迟：
  • 关注点：RocketMQ 极度依赖 PageCache。如果 flushDiskTime 或 commitLogSyncTime 飙升，会导致严重的消息写入阻塞。

3. 基础架构与 JVM 维度

• System Load / CPU Usage：CPU 负载过高会导致 Broker 处理请求缓慢，引发 Producer 侧的 TimeoutException。
• Disk IOPS / IO Wait：磁盘 IO 是 MQ 最核心的硬件资源，IO Wait 过高说明磁盘写入跟不上。
• Network In / Out：检查网卡带宽是否被打满。
• JVM GC 状态 (YGC / FGC)：
  • 关注点：重点监控 Full GC 的次数和耗时。频繁的 Full GC 会导致 Stop-The-World (STW)，直接表现就是 Broker 出现不可用、网络连接断开。

4. 高可用与集群维度

• Node Status（节点存活状态）：
  • NameServer 和 Broker 进程是否存活。
• Slave Fall Behind（主从同步延迟）：
  • 含义：在多 Master 多 Slave 架构中，Slave 节点落后 Master 节点的数据量（字节数）。
  • 关注点：如果主从同步延迟过大，在 Master 宕机时，会导致数据丢失风险增加，或者影响读写分离架构下的拉取性能。

---

三、 建议的告警阈值设置示例（供参考）

构建好监控后，合理的告警规则是自动化运维的关键。以下是一些经验阈值：

总结

做好 RocketMQ 的监控，核心思路是：外抓业务体验（消息积压 Lag、发送延迟），内防资源瓶颈（磁盘使用率、内存 GC、主从同步）。通过 Prometheus + RocketMQ Exporter + Grafana 的体系，配合合理的告警规则，即可保障大部分企业级生产集群的稳定运行。