关于 RocketMQ 的更多实战避坑指南,可访问「RocketMQ 中文社区」查看领域专家QA实录👨💻
从消息的生命周期看可观测能力
在进入主题之前先来看一下 RocketMQ 生产者、消费者和服务端交互的流程:

message produce and consume process
RocketMQ 的消息是按照队列的方式分区有序储存的,这种队列模型使得生产者、消费者和读写队列都是多对多的映射关系,彼此之间可以无限水平扩展。对比传统的消息队列如 RabbitMQ 是很大的优势,尤其是在流式处理场景下能够保证同一队列的消息被相同的消费者处理,对于批量处理、聚合处理更友好。
接下来我们来看一下消息的整个生命周期中需要关注的重要节点:

message life cycle
首先是消息发送:发送耗时是指一条消息从生产者开始发送到服务端接收到并储存在硬盘上的时间。如果是定时消息,需要到达指定的定时时间才能被消费者可见。
服务端收到消息后需要根据消息类型进行处理,对于定时/事务消息只有到了定时时间/事务提交才对消费者可见。RocketMQ 提供了消息堆积的特性,即消息发送到服务端后并不一定立即被拉取,可以按照客户端的消费能力进行投递。
从消费者的角度上看,有三个需要关注的阶段:
- 拉取消息:消息从开始拉取到抵达客户端的网络和服务端处理耗时;
- 消息排队:等待处理资源,即从消息抵达客户端到开始处理消息;
- 消息消费:从开始处理消息到最后提交位点/返回 ACK。
消息在生命周期的任何一个阶段,都可以清晰地被定义并且被观测到,这就是 RocketMQ 可观测的核心理念。而本文要介绍的 Metrics 就践行了这种理念,提供覆盖消息生命周期各个阶段的监控埋点。借助 Metrics 提供的原子能力我们可以搭建适合业务需要的监控系统:
- 日常巡检与监控预警;
- 宏观趋势/集群容量分析;
- 故障问题诊断。
RocketMQ 4.x Metrics 实现 – Exporter
RocketMQ 团队贡献的 RocketMQ exporter 已被 Prometheus 官方的开源 Exporter 生态所收录,提供了 Broker、Producer、Consumer 各个阶段丰富的监控指标。

最低0.47元/天 解锁文章
2110

被折叠的 条评论
为什么被折叠?



