RocketMQ 4.0可观测性体系搭建：指标、链路与告警实战

RocketMQ 做消息中台也快四年了从 3.x 一直跟到 4.0期间踩过的坑、半夜爬起来看的告警加起来能写一本小册子。今天想聊的是“可观测”这件事。很多团队把 RocketMQ 当黑盒用能发能收就觉得没问题等真出故障了只能在控制台瞎翻连“消息到底堵在哪一层”都说不清。4.0 版本在可观测性上其实做了不少东西但大部分人的用法还停留在“看个监控图”的阶段很浪费。这篇就把我在阿里云上做 RocketMQ 4.0 可观测体系的经验摊开讲讲清楚每一层要看什么、为什么看、怎么落地希望能帮你少走弯路。本文适合谁如果你的系统里跑着 RocketMQ 4.0或者正准备从老版本升上来又恰好被“消费延迟到底怎么告警”“Broker 节点磁盘打满为什么没发现”这类问题困扰过那这篇内容应该能直接派上用场。我会从整体框架、指标设计、链路追踪、告警规则、问题排查几个维度展开尽量还原真实落地过程。1. 可观测性这件事RocketMQ 为什么绕不开1.1 业务链路里的“黑盒”痛点先讲一个我印象很深的线上事故。当时某业务用 RocketMQ 同步订单状态变更上游服务发布消息下游消费服务负责更新数据库。某天凌晨数据对不上业务方找到我们时第一句话是“消息是不是丢了”。我们把 RocketMQ 控制台翻了个底朝天确认 Broker 端没有消息丢失。但“Broker 没丢”不等于“链路没断”——最后排查才发现消费端某个线程池被慢 SQL 拖垮消费速度跟不上生产速度积压量持续上涨业务数据自然越落越偏。这件事暴露了一个典型问题传统监控只能告诉你“Broker 还活着”但回答不了“消息是否在正确的时间被正确的人处理”。RocketMQ 的链路涉及 Producer、NameServer、Broker、Consumer Group、消费线程池、下游存储任何一环开小差表现出来的症状可能都是“消息不对”。要搞清故障到底在哪一环就需要一套贯穿整个链路的可观测体系而不是给 RocketMQ 装个“健康检查”就完事。1.2 从监控到可观测三个支柱的视角切换4.0 时代对可观测性的理解和以前不太一样。以前讲“监控”核心是 MetricsCPU、内存、磁盘、堆积量画几个折线图就收工。现在的“可观测”讲究的是 Metrics、Logs、Traces 三者联动。用一个生活化的类比相当于开车时仪表盘Metrics告诉你发动机转速偏高日志Logs相当于行车记录仪能回放具体时间点发生了什么链路追踪Traces则是完整导航路线告诉你这条消息从出发到抵达每一站花了多久、在哪里堵了。Metrics 回答“有没有问题”Broker 吞吐量、消费堆积、RT 等指标异常。Logs 回答“发生了什么问题”异常堆栈、错误码、系统日志里的告警信息。Traces 回答“问题出在链路哪一段”一条消息从 Producer 发出到 Consumer 消费完成每一步的耗时和状态。只有这三个维度组合起来才算真正的可观测。单独看任何一类都只能算“盲人摸象”。这也是本文所有落地实践的核心指导思想。2. 架构与指标设计先定框架再谈配置2.1 四层观测目标怎么拆开始动手配指标前我建议先把 RocketMQ 的部署结构拆开来看。RocketMQ 4.0 在阿里云上的典型部署可以分为四层每一层的可观测重点完全不同层级组件可观测重点常见问题接入层Producer / Consumer 客户端发送耗时、消费耗时、失败率、重试次数超时、流控、序列化问题协调层NameServer路由变更、请求量、节点健康路由抖动、全量请求压力存储层Broker写入耗时、刷盘状态、PageCache、磁盘水位、GC磁盘满、写入抖动、消息积压业务层Consumer Group / Topic消费堆积量、消费位点、各分区消费情况消费停滞、位点重置、重复消费很多人配置可观测时只盯着第三层和第四层觉得“Broker 没问题消费不积压”就可以。但实际上客户端层的网络超时、序列化耗时往往是消息“慢”的根源。为什么强调四层都看因为 RocketMQ 的客户端行为高度依赖参数配置比如sendMsgTimeout、消费线程数、批量拉取大小这些参数出了问题Broker 端指标再健康业务感知也是“卡顿”。2.2 核心指标清单与阈值建议结合我自己的运维经验整理了一份 RocketMQ 4.0 可观测性里必须关注的核心指标清单。这里不追求大而全只列真正影响线上稳定性的每项都附上我建议的阈值和告警策略。Broker 存储层核心指标写入 TPS / 写入 RTp99RocketMQ 性能最敏感的指标。P99 写入耗时超过 20ms 就该关注超过 50ms 基本意味着磁盘或 PageCache 出问题了。刷盘耗时FLUSH_DISK_TIMES/FLUSH_DISK_COST_TIME同步刷盘模式下这个指标直接决定端到端延迟。我一般要求刷盘耗时 P99 小于 10ms。磁盘水位数据目录磁盘使用率超过 70% 就要规划清理或扩容超过 85% 必须立刻排查。RocketMQ 的 commitlog 和 consumequeue 文件占空间很大很多人都栽在这里。JVM 老年代内存占用和 Full GC 次数RocketMQ Broker 默认堆内存不小但高并发下 GC 抖动一旦出现消费端会经历明显的“静默”期。Full GC 超过每分钟 1 次需要立即介入。消费消费链路核心指标消费堆积量Consumer Lag这个指标最具迷惑性后面专门讲。简单说只看堆积量还不够要看“堆积增长速率”。消费 TPS 与消费 RT消费 TPS 突然掉一半大概率消费者出问题了。消费失败次数失败率超过 0.1% 就值得关注超过 0.5% 建议报警。消费位点Offset进度查看是否长时间没有更新。客户端层核心指标Producer 发送成功率低于 99.9% 就要查网络或 Broker 压力。发送耗时分布P99/P999RocketMQ 发送 P99 超过 50ms往往不是 Broker 问题而是客户端所在宿主机的网络或线程调度问题。消费线程池活跃线程数线程池被打满表现为消费 RT 暴增。2.3 埋点与采样策略指标设计好了怎么埋在阿里云环境最省事的方式是使用 ARMS 的 Java Agent 做自动埋点它能自动识别 RocketMQ 的 Producer 和 Consumer 客户端无需改代码即可采集消息轨迹和调用链数据。但如果你是自建 Prometheus 体系就要在客户端显式埋点。以 Java 客户端为例我常用的埋点方式有两种方式一使用 Prometheus 客户端库手动埋点在应用的 RocketMQ 监听器里对消费耗时做统计// 生产者发送耗时埋点 public class OrderProducer { private final Histogram sendRtHistogram Histogram.build() .name(rocketmq_producer_send_rt) .help(Send message RT.) .labelNames(topic, status) .register(); public void send(Message msg) { long start System.currentTimeMillis(); try { producer.send(msg); sendRtHistogram.labels(msg.getTopic(), success).observe(System.currentTimeMillis() - start); } catch (Exception e) { sendRtHistogram.labels(msg.getTopic(), fail).observe(System.currentTimeMillis() - start); throw e; } } }// 消费端埋点在消息监听器里统计消费耗时和失败情况 public class OrderConsumerListener implements MessageListenerConcurrently { private final Histogram consumeRtHistogram Histogram.build() .name(rocketmq_consumer_consume_rt) .help(Consume message RT.) .labelNames(topic, consumer_group, status) .register(); private final Counter consumeCounter Counter.build() .name(rocketmq_consumer_consume_total) .labelNames(topic, consumer_group, status) .register(); Override public ConsumeConcurrentlyStatus consumeMessage(ListMessageExt msgs, ConsumeConcurrentlyContext context) { long start System.currentTimeMillis(); try { // 业务消费逻辑 consumeCounter.labels(msgs.get(0).getTopic(), context.getMessageQueue().getBrokerName(), success).inc(); return ConsumeConcurrentlyStatus.CONSUME_SUCCESS; } catch (Exception e) { consumeCounter.labels(msgs.get(0).getTopic(), context.getMessageQueue().getBrokerName(), fail).inc(); return ConsumeConcurrentlyStatus.RECONSUME_LATER; } finally { consumeRtHistogram.labels(msgs.get(0).getTopic(), context.getMessageQueue().getBrokerName(), all) .observe(System.currentTimeMillis() - start); } } }注意消费端的“失败”指标建议区分RECONSUME_LATER和真正的异常。RocketMQ 的消费重试机制是把消息重新投递到重试队列这种情况下消费失败指标会伴随“重试消息消费”统计必须结合消息轨迹才能区分是业务问题还是消费代码问题。采样策略上我采用的是“全量指标 部分链路”的组合。指标用全量采集成本可以接受链路追踪采用固定采样加动态采样。固定采样核心交易 Topic 100% 采样非核心 Topic 10% 采样。动态采样当某个 Topic 出现消费延迟或失败率上升时临时提高采样率到 100%故障恢复后回落。这样既能保证核心链路可完整追踪又不会让链路存储成本爆炸。3. 实操过程阿里云环境下的完整落地3.1 准备工作与采集端部署下面这部分是实打实的操作过程基于阿里云 ECS 阿里云 RocketMQ 4.0 实例来展开。假设你的 RocketMQ 用的是云服务版本那么 Broker 和 NameServer 层的指标其实已经由云厂商采集我们需要补的是客户端指标和链路追踪。如果你的 RocketMQ 是自建的需要在 Broker 节点上额外部署 node_exporter 或使用 JMX 导出 Broker 的 JVM 和存储指标。RocketMQ 的 Broker 支持通过mqbroker启动参数开启 JMX端口默认 1099。因为 Broker 在 JVM 里JVM 指标如堆内存、GC 次数对定位问题极其关键务必采集。我当时的部署架构是这样的使用阿里云 Prometheus 服务ARMS Prometheus作为指标存储和查询引擎在业务 ECS 上部署 Prometheus Agent 或使用阿里云 Agent 采集自定义埋点指标将 RocketMQ 客户端埋点的指标通过 Prometheus 协议暴露最终抓到 ARMS Prometheus 里链路追踪接入 ARMS 的 Java Agent自动采集中间件链路日志走阿里云 SLS按 Broker ID、Topic、Consumer Group 建索引。这套架构的好处是指标、日志、链路全部归属于同一家云产品排查时可以一键从曲线图跳到对应的日志再从日志枚举关联 TraceID少了很多跨系统切换的成本。3.2 核心指标大盘搭建指标采集到位后首先应该有一套“一眼看出问题”的大盘而不是每次临时去写 PromQL。我当时用 Grafana 搭了五个核心面板仪表盘设计也遵循四层观测的逻辑面板一Broker 写入与存储健康这个面板放四个图写入 TPS写入 RT P99/P99.9刷盘耗时磁盘使用率。它解决的核心问题是“Broker 到底还能撑多久”。实际操作中最值得看的是写入 RT 的变化趋势。如果 TPS 平稳但 RT 缓慢爬坡十有八九是磁盘或 PageCache 出了问题早发现早处理。面板二消费链路健康按 Consumer Group 维度展示消费 TPS、消费堆积量、消费 RT、消费失败率。这里我会特意把堆积量做成柱状图按 Topic 分组排序让积压最严重的 Group 永远排在第一位。每天上班先扫一眼这个面板比看几十封邮件管用得多。面板三客户端与宿主机资源展示各业务实例的 CPU、内存、网络 IO以及 RocketMQ 发送/消费 RT。为什么要看宿主机因为很多 RocketMQ 的“慢”根本不是 RocketMQ 的问题而是业务应用所在的 ECS 本身 CPU 争抢严重。不看宿主机就容易误伤中间件。面板四链路与轨迹按 Topic 展示消息从生产到消费的端到端耗时分布。这个面板和第一个面板的区别是第一个看 Broker 单点这里看的是完整链路。如果端到端耗时偏高但 Broker 写入正常问题就出在业务代码或网络传输上。面板五告警事件与变更记录把告警通知、配置变更、发布记录放到一个时间轴视图。这个面板是我后来加上的因为排查时最怕“指标异常原因不明”把告警和变更合在一起方便直接找出“哦原来那天下了一个调参变更”。3.3 链路追踪与日志关联指标只能告诉你“哪里出问题”链路追踪才能告诉你“为什么出问题”。RocketMQ 4.0 的客户端内置了消息轨迹Message Trace能力可以记录一条消息从生产、存储到消费的完整生命周期包括生产时间、发送结果、Broker 地址存储位点、是否写入成功消费时间、消费结果、消费次数。在阿里云 ARMS 里开启消息轨迹的方式比较简单控制台开启 trace 采样比例或者在客户端显式配置开启。如果是自建链路系统比如 SkyWalking 或 Jaeger重点要看的是 RocketMQ 消息上下文能否跨进程透传。RocketMQ 客户端发送消息时会携带消息属性我们可以把 TraceID 注入到消息的自定义属性里消费者端再从中提取// 生产端注入 TraceID 到消息属性 Message msg new Message(TOPIC, body); msg.putUserProperty(traceId, TraceContext.getTraceId()); msg.putUserProperty(spanId, TraceContext.getSpanId()); // 消费端从消息属性中提取 TraceID public ConsumeConcurrentlyStatus consumeMessage(ListMessageExt msgs, ConsumeConcurrentlyContext context) { MessageExt msg msgs.get(0); String traceId msg.getUserProperty(traceId); // 用 traceId 将消费端 span 关联到同一链路 // 业务处理... }这里有一个坑RocketMQ 的消息属性如果是自定义字符串Broker 会原样存储但要注意消息体过大影响网络传输建议只传 TraceID、SpanID 这类短字段。日志关联方面我习惯为每条消费日志统一打印 Topic、Consumer Group、MessageID、TraceID。这样遇到问题可以直接用 MessageID 或 TraceID 在 SLS 里把全链路日志捞出来。日志格式建议固定为[Topic:order_status_change][Group:order-center][MsgId:1A2B3C4D][TraceId:xxx][ReceiveTime:...][Cost:...]这个格式帮我解决过不止一次线上问题直接grep MessageID就能把一条消息从生产到消费的所有日志串起来。3.4 告警规则配置实战告警配置是最容易走极端的环节要么太少出事没人知道要么太多天天狼来了把人搞麻木。我总结的告警配置原则是“三层分级、动静结合”。第一层立刻处理P0/P1短信电话Broker 磁盘使用率超过 85%持续 5 分钟消费堆积量持续增长且消费 TPS 降为 0持续 3 分钟Producer 发送成功率低于 99%持续 5 分钟核心 Topic 消费端到端延迟超过 10 分钟。第二层重点关注P2短信通知Broker 写入 RT P99 超过 50ms持续 10 分钟消费堆积量超过阈值但消费 TPS 正常Full GC 次数超过阈值消费失败率超过 0.5%。第三层趋势观察P3仅在工作时间邮件通知非核心 Topic 消费延迟升高磁盘使用率超过 70%客户端发送耗时 P99 缓慢上升。在这里要特别强调一个理念告警不能只配一个静态阈值更要看“变化率”。比如消费堆积堆积 1 万条可能完全正常但如果堆积量 10 分钟翻了 5 倍即使绝对值不高也要重点关注。所以我在告警规则里大量使用 PromQL 的deriv()或rate()函数来捕捉趋势变化而不是单纯卡死一个绝对值。4. 常见问题与排查技巧实录4.1 指标对不上客户端视角和 Broker 视角这是我在一开始布置可观测性时常遇到的问题客户端埋点显示的发送耗时是 50ms但 Broker 端写入耗时显示只有 2ms到底该信谁答案是两个都信但含义不同。客户端耗时包括网络传输、Broker 处理、客户端自身线程调度而 Broker 耗时只统计内部写入处理。两者差出来的部分往往是网络或客户端所在宿主机的瓶颈。排查时我习惯按这个顺序拆先看客户端所在 ECS 的 CPU 和内存使用再看网卡流量和丢包率最后才看是否有网络延迟。如果客户端宿主机的 CPU 已经打满那么发送耗时再高也不用怀疑中间件先把业务应用的性能问题解决了再说。值得注意的是RocketMQ 客户端的send()方法在发送失败时会走重试逻辑默认重试 3 次每次间隔递增。所以如果你看到发送 RT 曲线有规律的“毛刺”可能不是网络抖动而是某个请求触发了重试。判断方法是把成功和失败的发送耗时分开埋点如果失败重试请求持续出现大概率是 Topic 对应的 Broker 出现了短时异常。4.2 消费延迟告警误报的原因消费堆积是一项被误读最多的指标。很多人看到堆积量上涨就认为消费者出了问题其实未必。我自己碰到过几种典型情况第一种是“批量消费吞吐上升”。比如上游做活动消息洪峰到来消费 TPS 虽然上涨但本来就该堆积消费端也在全力处理这时堆积是健康的。判断标准消费 TPS 和堆积量同步上涨但堆积增长速率低于消费 TPS 时说明消费者吃得住。第二种是“消费线程池参数问题”。RocketMQ 默认的消费线程数是 20如果你的消费逻辑包含远程调用或数据库操作20 个线程根本不够用。线程池被打满后堆积量线性上涨。排查办法看消费 RT 是否超过正常水平再看消费线程活跃数是否达到最大值。第三种是“GC 导致消费停滞”。JVM 发生长时间 Full GC 时消费线程会全部阻塞表现为消费 TPS 归零、堆积量急速增加业务方看到的就是“消费者挂掉了”。但如果看 JVM 监控进程还活着只是 GC 日志里长时间停顿。这种问题靠指标很难第一时间发现建议给 JVM GC 时间单独配一个告警。所以我的建议是消费延迟告警不能只看堆积量绝对值要设定“堆积增长速率”和“消费 TPS 趋势”两个条件同时触发才算告警否则洪峰期间全是误报。4.3 RocketMQ 4.0 的 GC 抖动与磁盘问题再分享两个在 RocketMQ 4.0 上比较坑的实践经验。第一个是 GC 抖动。RocketMQ 4.0 的 Broker 内部使用了很多偏向于大对象的存储结构高并发写入时老年代内存增长很快频繁触发 CMFConcurrent Mode Failure。CMF 会导致 Broker 的 Stop-The-World 停顿表现为写入 RT 突然飙升到几百毫秒甚至几秒。定位 GC 抖动最好的办法是开启 GC 日志并在告警时把 GC 耗时和写入 RT 曲线叠加对比。如果两者高度吻合基本可以确定是 GC 导致。处理手段通常是调整 JVM 参数比如增大新生代、调整 CMS 触发比例等但这些参数必须结合压测数据来调不建议照抄网上的配置。第二个是磁盘问题。RocketMQ 的 commitlog 文件默认单个 1GBconsumequeue 默认 5.72MB。在高吞吐场景下磁盘写入量是消息体大小的数倍加上刷盘、复制、索引等。我遇到过磁盘用满结果是 commitlog 文件堆积导致的“已使用空间正常、但 inode 耗尽”的情况。所以磁盘监控除了看使用率还要看 inode 使用率。这里有个经验磁盘使用率超过 70% 就要看 commitlog 目录里是否有大量未删除的历史文件。RocketMQ 的默认策略是消息消费超过 72 小时后删除文件但如果你频繁使用reset offset会导致部分消息永远无法被正常消费掉文件一直不删除磁盘迟早打满。4.4 排查工具速查表把我在实际排查时常用的工具和命令整理成一张速查表遇到问题先从上往下试问题症状第一步排查关键命令 / 入口消息发送超时查客户端 ECS 的网络和 CPUtop、sar -n DEV 1、dmesg消费堆积上涨确认消费 TPS 是否下降RocketMQ 控制台消费组监控页消费 RT 突然变高看消费线程池活跃数和 GCjstat -gcutil pid 1000消息丢失疑似查消息轨迹和消费重试队列控制台“消息轨迹”或 SLS 日志Broker 节点异常查看 Broker 主备切换状态mqadmin clusterList、mqadmin brokerStatus磁盘空间不足确认 commitlog 和 inode 使用率df -h、df -i、lsof关于mqadmin多说一句。很多人在排查时只盯控制台其实mqadmin很多命令能直接给出 Broker 内部状态比如查看某个 Topic 的读写队列、查看消费组消费位点等。比如# 查看指定 broker 上的 topic 路由信息 mqadmin topicRoute -n namesrvAddr -t topic # 查看消费组位点信息 mqadmin consumerProgress -n namesrvAddr -g consumerGroup这些命令的输出比控制台更原生、更直接尤其是定位位点不一致、队列分配异常这类问题几乎必不可少。5. 最后的实操经验与避坑建议这篇文章写到最后我想再聊几个在真实环境里摸索出来的“潜规则”这些内容通常不会出现在官方文档里但对保证可观测体系的持续有效非常关键。首先可观测体系不是搭完就完事的建议每季度做一次“告警有效性演练”。具体做法是挑一个低峰时段人为给测试 Topic 灌入异常流量看看告警是否如期触发、通知是否到达正确的人、告警内容里的维度信息是否足够定位问题。我做过一次演练发现有三个告警因为 PromQL 里 label 拼写错误压根没触发过如果不演练真出事那天就只能靠运气了。其次指标的 label 设计要“克制”。我最初埋点时给每个指标加了七八个 label包括 IP、Topic、Group、Broker、环境、版本结果 Prometheus 的存储压力剧增而且部分 label 基数极大比如 IP直接拖慢了查询速度。后来把高基数 label 从指标里移除只保留“环境 Topic Group”这三个核心维度查询速度显著提升。如果你确实需要按 IP 筛选可以单独开一张信息表在 Grafana 里做 join而不是塞进指标里。最后链路追踪的采样率不是越高越好。我在某个凌晨被一条链路存储账单吓到过因为上线时把核心 Topic 和非核心 Topic 都调成了 100% 采样一天产生的 trace 数据比之前一个月还多。最终我定下的规矩是“核心链路 100%边缘链路 10%异常全采”并且在一周内复盘采样比例是否合理。可观测这件事投入产出不成正比的时候确实有但踩过几次线上下不来的坑之后你会充分理解它的价值。希望这篇基于阿里云 RocketMQ 4.0 的实践总结能帮你搭建一套真正可用的观测体系。如果你在落地过程中遇到什么有意思的问题也欢迎一起交流毕竟消息队列比想象中更容易出幺蛾子。