开发者学堂课程【消息队列 RocketMQ 5.0 云原生架构升级课程：RocketMQ 5.0 可观测能力升级: Metrics 指标分析介绍】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1234/detail/18402
Rocket MQ 5.0 可观测能力升级: Metrics 指标分析介绍
内容介绍：
一、从消息的生命周期看 Rocket MQ 可观测性
二、Rocket MQ 4.X Metrics 实现
三、Rocket MQ 5.X Metrics 实现
四、构建监控体系最佳实践
本次为大家介绍Rocket MQ 5.0可观测性系列的课程，本课程的主题是绕RocketMQ 5.0指标的分析。首先介绍本次课程的主要内容，分为四个部分，首先是从消息的整个生命周期来看Rocket MQ的观测性，其次是介绍Rocket MQ 4.0和Rocket MQ 5.0中Metrics的区别和提升，最后是一些最佳实践的推荐。
一、从消息的生命周期看 Rocket MQ 可观测性
首先介绍第一部分，从消息的生命周期看Rocket MQ 的可观测性，
可观测性能力是围绕着消息的生命周期构建的，所以在介绍Rocket MQ Metrics的功能之前，先要介绍Rocket MQ消息的生产、堆积、拉取、消费的整个流程。
上图是生产者、消费者和服务端交互的流程，可以看到Rocket MQ的消息是按照队列的方式有序储存的，Rocket MQ的队列模型使得生产者、消费者和读写队列之间都是多对多的映射关系。彼此之间都可以无限水平拓展，这一点与传统的消息对比，比如Rocket MQ是很大的优势，尤其是在流式处理的场景下有着天然的优势，因为它能够保证同一队列的消息被相同的消费者处理，对于批量处理、聚合处理更为友好。
接下来介绍消息的整个生命周期中需要关注的一些重要节点。首先是消息发送，发送耗时是指一个消息从生产者开始生产消息，开始发送到服务端接收并且储存到硬盘上的时间就是图中的前两部分。如果是定时消息或者事务消息需要到达指定定时时间或者事务被提交才能被消费者可见。
接下来就是消息堆积的部分，Rocket MQ提供了消息堆积的特性，即消息发送到服务端后并不一定立即被拉取，可以按照客户端的消费能力进行投递。这段时间中消息是被堆积在服务端的，也就是图中的ready time 至start pull time之间。
从消费者的角度来看，需要关注的三个阶段。首先是拉取消息，消息从开始拉取到抵达客户端的网络和服务端处理耗时，也就是pull RBC的耗时，就是对应着图中的网络耗时这部分。第二个阶段是等待处理资源的阶段，即消息从抵达客户端开始到开始处理消息这一个流程。接下来介绍，从消费者的角度上看，需要关注的三个阶段。首先是拉取消息的接口耗时，也就是消息从开始拉取到抵达客户端的网络和服务端处理耗时。对应的图中的网络耗时这部分。第二部分是消息排队的时间，即消息到抵达客户端一直到开始消费这条消息这段等待资源的耗时。第三个阶段是消息消费耗时，即真正的消息逻辑的耗时，这就是消息从生产到消费的整个生命周期。
二、Rocket MQ 4.X Metrics
接下来介绍Rocket MQ 4.0 中是如何围绕着生命周期进行 Metrics能力的建设。
Rocket MQ 4.0是由exporter组件来实现的，Rocket MQ 团队贡献的Rocket MQ exporter 已经被Prometheus官方开源生态所收录。这个组件提供了broker 、producer、consumer等各个阶段丰富的监控指标，图中列出了一些消费者相关的指标。
接下来看一下exporter的原理，Rocket MQ exporter获取监控指标的流程如上图所示，首先通过MQ Admin Ext向Rocket MQ的集群请求数据，然后再将获取的数据在本地内存中转换成Prometheus需要的格式，然后通过 Metrics的point暴露出来。Rocket MQ exporter过去确实在一定程度上满足了对 Metrics能力的需要，但是随着 Metrics的操作模式的改变也逐渐暴露出一些缺陷。
比如无法支持Rocket MQ 5.0中新加入一些组件，比如Prometheus的客观性需求，其实是它的指标定义不符合开源标准。对无法无痛的接入一些Metrics的相关相关组件。
另外就是通过MQ Admin Ext向Rocket MQ的集群请求数据，造成大量的Rocket MQ调用，这种方式会带来额外的压力。为了解决以上问题，在 Rocket MQ 5.0推出的基于open telemtry 的 Metrics策划案，就是要介绍的下一部分。
三、Rocket MQ 5.X Metrics 实现
Rocket MQ 5.0对Metrics的实现。它是CNCF的一个可观测性项目，旨在提供可观测性领域的标准化方案，解决观测数据的数据模型、采集、处理、导出等的标准化问题，提供与vendor无关的服务。Rocket MQ在设计新的Metrics方案是决定遵循open telemtry 的社区规范，现在Metrics的指标完全是重新设计，数据类型选用兼容Prometheus的counter、Guage、Histogram，并且完全遵循Prometheus指标的命令规范，经过重新设计的指标，与exporter的指标名字并不兼容，功能是完全可以替代的，新的指标覆盖了broker、proxy、producer、consumer等一些组件对消息生命周期的全阶段提供监控的能力。
Rocket MQ新的Metrics指标分为两种方式。首先介绍第一种指标上报pull模式，pull模式只带Prometheus兼容，特别是在K8s部署环境中，如上图所示，Prometheus可以通过一些服务行业机制。比如图中示意的是Prometheus可以直接从broker、或者proxy提供的endpoint中拉取数据，无需部署额外的组件。
第二种指标上报方式是push模式，这也是open telemtry 推荐使用的模式，需要额外部署一个collector来传输指标数据，broker将采集到的数据上报至collector中，然后collector再根据用户的配置对指标做一些自定义操作，比如指标的过滤、富化等。然后将处理好的指标上报到比如Prometheus这种的Metrics数据中。新的Metrics也支持对collector的兼容，现在使用Metrics的用户无需变更数据架构即可接入新的Metrics进行使用。而且有限公司对安全的要求是比较强的，应用和应用之间需要很强的隔离性。比如控制界面的应用，可能就是这种和数据下的应用，比如Rocket MQ可能是需要隔离部署，因此接触过reporter来作为跨网络的一个代理来获取Metrics的数据也不失为一种比较好的选择。
接下来具体看一下现在Metrics是如何实现对exporter模式的兼容。在Rocket MQ exporter中实现一个open telemtry collector。Broker将Metrics的数据导出到reporter中，reporter把这些数据转换成Prometheus的格式，为 Prometheus的访问提供了一个新的endpoint，即图中所示的endpoint VR。
四、构建监控体系最佳实践
介绍完Rocket MQ 5.0在Metrics中的实现之后，接下来给出一些最佳实践的推荐，介绍如何根据Metrics的能力来构建我们的监控体系。
Rocket MQ的Metrics能力以及对社区标准的遵循，使得可以轻而易举他借助一些开源组件，比如bronisry或者wehana来贡献监控体系。首先将broker或者是consumer指标采集到bronisry，然后就可以基于这些指标在wehana配出一些监护大牌，这里给出一些事例。上图中就是一些对接口耗时、成功、失败率以及请求分布。
上图是客户端的数量，客户端的版本分布以及消息类型，消息大小的分布监控。
上图是Broker的一些状态监控，比如一些patch延迟、消息保留时间堆积比较多的topic、group，还有broker上的一些线上消息的堆积情况。
有了完善的监控，就可以对需要关注的指标配置告警，而收到告警后又可以联动监控来分析告警的具体原因。如上图所示，收到了一个消息延迟的告警，可以通过监控看到本次延迟的原因是有一定的消费失败，然后消费失败的具体原因可以看右边的界面，可以看到是因为订阅并不存在。通过告警和监控的互相配合，就可以做到快速发现问题，快速定位问题。现在以一个实际例子来介绍如何通过Metrics分析堆积问题。
先回顾一下之前讲解过的消息生命周期，对于堆积问题，主要关注消息周期中的两个阶段。第一个阶段是就绪消息，就绪消息是可供消费，但还未被拉取的消息，即在服务端堆积的消息，对应上图中的绿色部分。第二阶段是处理中的消息，处理中的消息是指被客户端拉取，但是还未被消费的消息，也就是在客户端中对应的消息，对应图中的橙色阶段。
关于就绪消息和处理中消息我们提供了
rocketmq_consumer_ready_messages
和rocketmq_consumer_inflight_messages这两个指标，结合这两个指标和其他指标以及对客户端配置的综合分析，即可判断出消息堆积的原因。以下举几个真实的case具体情况具体分析。首先第一个case，就绪消息的数量持续上涨，而处理中的消息达到客户端的堆积上限后几乎不变。这是最常见的堆积场景，客户端处理中的消息量达到了客户端配置的最高阈值，即消费者的消费能力低于消息的发送速度，此时需要根据业务的需要，灵活决定是增加消费者数量来尽快的调节消息，还是等待业务高峰过去之后再慢慢消化堆积的消息。
接下来介绍第二个case，就绪消息几乎为零，而处理中的消息持续上涨。这个case一般出现在使用Rocket MQ 4.0的客户端场景，此时消费的位点是按消费顺序来进行提交的，如果某条消息的消费卡住就会导致当前的消费位点无法提交，现象就是消息在客户端的大量堆积。可以结合消费轨迹和rocketmq_process_time这个指标抓出消费慢的消息，并分析这条消息消费的上下游链路，找到消息消费慢的根因。
之后介绍第三个case，就绪消息持续上涨，但是处理中的消息几乎为零。
这种场景说明客户端没有拉取到消息，一般来说有如下几种情况：第一种情况是遇到了鉴权问题，如果开启了ACL或者使用了公有云的消息产品，那么检查一下资源是否有权限；第二种情况是消费者夯住，这时候我们可以尝试打印线程堆栈或者gc信息，判断是否进程夯住，夯在哪里，针对此做一个解决方案。最后一种情况是服务端响应比较慢，可以结合RPC相关的指标查看拉取消息接口的调用量和耗时检查是否正常来判断是否为客户端的问题，比如遇到磁盘IO被打满等这类情况。
以上是本次课程的全部内容。
