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