这是《RocketMQ 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 监控的目标是在用户感知前发现风险，在故障发生时快速定位层级。RocketMQ 监控至少覆盖四条线：集群健康、生产链路、消费链路和资源容量，并把它们与业务指标放在同一时间线。
22.1 监控分层
business metrics
-> application metrics
-> rocketmq client metrics
-> proxy metrics
-> broker metrics
-> storage / network / os metrics
单看 Broker TPS 正常并不能证明业务正常；单看消费成功也不代表下游数据正确。监控要支持端到端追踪。
22.2 集群健康
核心指标：
| 指标 | 含义 |
|---|---|
| broker_alive | Broker 是否在线 |
| broker_role | 主从角色 |
| broker_epoch | 角色任期 |
| nameserver_alive | NameServer 健康 |
| controller_leader | Controller 是否有主 |
| replica_sync_diff | 副本差距 |
| disk_usage_ratio | 磁盘使用率 |
| file_descriptor_count | 文件句柄 |
告警示例：
- Broker 离线；
- 无 Controller leader；
- 副本数量低于预期；
- 副本同步差距持续扩大；
- 磁盘使用率超过阈值；
- 频繁切换角色；
- NameServer 路由不一致。
22.3 生产监控
客户端指标：
producer_send_total
producer_send_success_total
producer_send_failure_total
producer_send_latency_ms
producer_retry_total
producer_timeout_total
producer_thread_waiting
local_outbox_pending
重点看：
- 成功率；
- P95 / P99 延迟；
- 超时率；
- 重试率；
- 本地待发送事件数量；
- 按 Topic 和服务维度聚合；
- 灰度版本差异。
发送异常必须记录 Topic、messageId、业务键、SendStatus 和错误码。
22.4 消费监控
指标：
consumer_group_online
consumer_lag
consumer_lag_bytes
consumer_oldest_message_age
consumer_pull_total
consumer_consume_total
consumer_success_total
consumer_failure_total
consumer_retry_total
consumer_dead_letter_total
consumer_consume_latency_ms
consumer_thread_pool_active
关键问题判断：
| 问题 | 可能原因 |
|---|---|
| 消费组不在线 | 实例崩溃、发布失败、配置错误 |
| lag 增长且耗时高 | 处理能力不足 |
| lag 增长但耗时低 | 订阅、位点或队列分配问题 |
| 重试增长 | 下游异常或代码缺陷 |
| 死信增长 | 无法自动恢复消息增加 |
| 消息年龄增长 | 积压严重 |
22.5 存储监控
指标：
broker_put_tps
broker_get_tps
broker_put_latency_ms
commitlog_flush_latency_ms
dispatch_lag
commitlog_file_count
disk_read_iops
disk_write_iops
disk_io_util
disk_io_wait
page_cache_ratio
典型判断：
- 写延迟与磁盘 util 同升，疑似磁盘瓶颈；
- dispatch lag 增长，索引构建落后；
- 冷读导致 page cache 命中下降；
- 拉取延迟高但磁盘低，可能是网络或过滤开销；
- 文件数量异常增长，检查队列和 Topic 扩张。
22.6 Proxy 监控
如果使用 Proxy 模式：
proxy_active_connections
proxy_request_total
proxy_error_total
proxy_request_latency_ms
proxy_upstream_latency_ms
proxy_route_refresh_total
proxy_auth_failure_total
proxy_memory_usage
重点：
- 连接增长趋势；
- 请求队列；
- 入口延迟与上游延迟差；
- 路由刷新异常；
- 认证失败；
- 优雅停机时间。
22.7 告警设计
告警要区分级别：
| 级别 | 场景 |
|---|---|
| P0 | 核心集群不可写、数据缺失、多副本不可用 |
| P1 | 核心消费组长时间积压、死信快速增长 |
| P2 | 副本落后、磁盘接近阈值、延迟升高 |
| P3 | 非核心 Topic 异常 |
避免只告警数量：
bad: dead letter > 100
good: dead letter unhandled age > 30m
每条告警应包含：
- 集群和环境；
- Topic 或消费组；
- 影响范围；
- 关键指标；
- 处理入口；
- 值班手册链接。
22.8 仪表盘
推荐仪表盘：
- 集群总览；
- Broker 详情；
- Topic 流量；
- 消费组健康；
- 生产应用视图；
- 消费应用视图；
- 死信治理；
- 容量和预测；
- 变更与事件时间线。
每张图都应支持按环境、集群、Broker、Topic、消费组、应用版本过滤。
22.9 日志与链路
日志统一携带：
traceId
messageId
eventId
businessKey
topic
consumerGroup
queueId
offset
与消息轨迹联动：
business exception
-> search event key
-> view message trace
-> locate application log
-> inspect downstream result
本章小结
RocketMQ 监控要从业务结果反推技术链路，覆盖生产端、Broker、存储、副本、消费端、死信和 Proxy。告警要关注趋势、年龄和影响范围，而不是静态数量。端到端的业务键与消息轨迹是高效排障的关键。
思考题
- lag 增长但消费耗时正常，可能是什么问题？
- 为什么死信年龄比死信数量更有意义？
- 生产重试率升高为什么要与 Broker 指标一起看？
- dispatch lag 会造成什么误判？
- Proxy 延迟和 Broker 延迟如何区分？