监控指标体系：端到端延迟、生产延迟、消费延迟、延迟百分位（P99/P999）
聊到消息延迟监控，很多人第一反应就是「看消费有没有积压」。嗯，这没错，但远远不够。我见过太多团队只盯着消费延迟这一个指标，结果线上出了大问题，排查半天才发现——生产端早就卡死了，消费端压根没收到消息。
说白了，延迟监控要分层次、分维度。今天我就把四个核心指标掰开揉碎讲清楚：端到端延迟、生产延迟、消费延迟，还有那个让人又爱又恨的P99/P999。
端到端延迟：用户感知的「真实延迟」
端到端延迟，指的是消息从生产者发出，到消费者真正处理完成所经过的总时间。这是最贴近业务体验的指标。
举个例子。你在电商平台下单，订单系统发出一条「创建订单」消息。这条消息经过MQ，最终被库存服务消费，扣减库存。从你点击「提交订单」到库存扣减完成，这中间的耗时，就是端到端延迟。
端到端延迟 = 消息消费时间戳 - 消息生产时间戳
我在项目中遇到过一个问题：端到端延迟突然飙升到10秒以上，但生产延迟和消费延迟各自看都正常。后来发现是消息在MQ内部排队太久——Broker的IO打满了。你看，只看局部指标根本发现不了。
生产延迟：消息「出门」花了多久
生产延迟，就是消息从业务代码调用发送接口，到MQ Broker确认收到这条消息的时间。说白了，就是消息「出门」的速度。
这个指标直接反映了生产者和MQ之间的网络状况、Broker的处理能力。如果生产延迟持续走高，说明要么网络有抖动，要么Broker扛不住了。
| 生产延迟范围 | 可能原因 | 建议措施 |
|---|---|---|
| < 5ms | 正常，网络和Broker状态良好 | 保持观察 |
| 5ms ~ 50ms | 网络轻微波动或Broker负载上升 | 检查网络延迟，关注Broker CPU |
| 50ms ~ 200ms | Broker可能出现瓶颈 | 考虑扩容或优化生产者发送策略 |
| > 200ms | 严重异常，可能丢消息或Broker宕机 | 立即排查，检查磁盘IO和GC |
我曾经遇到过一个案例：生产延迟偶尔飙到1秒以上，但平均延迟只有20ms。排查了很久，最后发现是生产者使用了同步发送，而Broker的刷盘策略是同步刷盘。每次刷盘时，所有发送请求都得排队。后来改成异步刷盘，问题就解决了。
消费延迟：消息「进门」后等了多久
消费延迟，指的是消息到达Broker之后，到被消费者真正拉取并开始处理的时间差。这个指标反映了消费者的处理能力和消费速度。
你想想看，如果消费延迟持续增长，说明消费者处理速度跟不上生产速度。这就是我们常说的「消息积压」。
消费延迟的计算方式很简单：
消费延迟 = 消息被消费的时间 - 消息到达Broker的时间但这里有个坑——消息到达Broker的时间怎么拿？很多MQ（比如RocketMQ）会在消息属性里自带存储时间戳。Kafka的话，可以通过消息的offset和timestamp索引来推算。
我个人习惯把消费延迟拆成两个子指标：
- 排队延迟：消息在Broker队列里等待被拉取的时间
- 处理延迟：消费者拉取到消息后，业务逻辑处理耗时
为什么要拆？因为排队延迟高，说明消费者拉取能力不足，可能是分区数不够或者消费者线程数太少。处理延迟高，说明业务逻辑本身慢，得优化代码或者扩容消费者实例。
延迟百分位：P99和P999才是「真相」
平均延迟是个骗人的东西。我见过一个系统，平均延迟20ms，但P99延迟500ms，P999延迟3秒。你想想看，如果只看平均值，你根本不知道有1%的用户在忍受500ms的延迟，0.1%的用户在忍受3秒的延迟。
P99的意思是：99%的请求延迟都小于这个值。P999同理，更严格。
因为消息系统的延迟分布往往不是正态分布，而是长尾分布。大部分消息很快，但总有那么一小撮消息特别慢。这些「慢消息」就是用户体验的杀手。
我在做监控时，一般会同时关注三个百分位：
- P50：中位数，反映整体水平
- P99：反映尾部延迟，99%的用户体验
- P999：反映极端情况，0.1%的异常请求
如果P99突然升高，但P50正常，说明系统出现了偶发性的抖动。可能是GC、网络波动、或者某个Broker节点负载不均。
如果P999持续走高，那就要警惕了——系统可能正在接近瓶颈，随时可能雪崩。
四个指标怎么配合使用？
光知道每个指标的定义还不够，关键是怎么用它们来定位问题。我画了一张图，把四个指标的关系理清楚了：
从这张图可以看得很清楚：
- 生产延迟 + 消费延迟 ≠ 端到端延迟。中间还有Broker内部的排队、刷盘、复制等耗时。
- P99/P999要分别对三个延迟指标计算。不能只看端到端的百分位，否则你分不清瓶颈在哪。
避坑指南
最后分享几个我踩过的坑：
- 不要用平均值做告警。我曾经用平均延迟做告警阈值，结果系统都快挂了，平均值才涨了20%。换成P99告警后，问题提前10分钟就被发现了。
- 时间戳要统一时区。生产者和消费者如果不在同一个时区，算出来的端到端延迟可能是负数。嗯，别问我怎么知道的。
- 采样率要足够高。如果只采样1%的消息算延迟，P99基本就是瞎猜。我建议全量采样，或者至少采样10%以上。
- 注意时钟同步。生产者和消费者所在机器的时钟如果不一致，端到端延迟就是错的。NTP一定要配好。
这四个指标，说白了就是一套组合拳。单看任何一个都有盲区，合在一起才能看清全貌。你想想看，如果只盯着消费延迟，生产端卡了你都不知道。如果只看平均值，那1%的慢消息就把用户坑惨了。
好了，这一章的内容就到这里。记住：监控不是为了看数据，而是为了在问题发生前发现它。