开发者学堂课程【消息队列 RocketMQ 5.0 云原生架构升级课程：RocketMQ 5.0 可观测能力升级: Tracing 链路追踪介绍】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：/learning/course/1234/detail/18398
Rocket MQ5.0 可观测能力升级: Tracing 链路追踪介绍
内容介绍：
一、Rocket MQ 5.0可观测全面升级
二、Rocket MQ Tracing的背景和需求
三、Rocket MQ 5.0 Tracing设计
四、Rocket MQ 5.0 Tracing最佳实践
今天给大家介绍一下RocketMQ5.0可观测系列中 Tracing链路追踪列入最终的部分,今天主要分四个部分，第一部分讲解5.0和4.0相比，可观测部分全面提升的地方；然后第二部分讲解Tracing的背景和需求；第三部分讲解5.0 Tracing设计的一些要点；第四部分讲解5.0 Tracing的数据带来的最佳实践。
一、Rocket MQ 5.0 可观测全面升级
对5.0的可观测的能力做了全面的提升，在Metrics 、Tracing 、Logging方面都做了提升，后续还会补给Events 事件，帮助大家作为定位排查。这些事件的提升其实主要是两个方面，一个是沉淀了云上多年的一些问题定位排查，帮客户排查各种各样复杂的业务产品问题，积累下来一些经验，然后特别设计了一些观测的一些数据，比如一些Metrics 、Tracing 的数据，推出了全新的一套指标。
这套指标是全面拥抱开源的生态，同时符合开源的生态的一些标准的，比如说Metrics 数据，它是符合普罗米修斯的一些标准数据，涵盖了各种各样消费场景的一些特殊数据需求，同时为用户提供了一些大牌模板。在 Tracing 数据上其实是做了一个比较大的改变，因为原来是用消息来实施的自定义的一些缺陷的格式实现，现在其实大家更多需求是要对接整个open Telemetry 的一个标准的生态，然后将Tracing 的数据符合开源生态的标准，然后让用户能够将数据对接到开源的系统上，并且能够连接消息上游和下游的 Tracing 的数据链路。目前Tracing新的标准已经开源到open Telemetry社区。Logging的话，其实是做了更多的一些标准化，格式化的处理，比如说标准权统一的Error Code的处理，然后有了一个完整性的排出和完整的格式化的梳理。新增的Events 事件就是其实也是一些需要帮助排查定位的，例如订阅关系变更、消费者上下线，容器重启等事件也是可以帮助定位排查的。
二、Rocket MQ Tracing 的背景和需求
现在展开讲解Tracing部分的内容，首先本身Tracing在消息链路来说，它其实是一个比较复杂的，比同步、pcc是要更复杂的，因为Tracing的消息链路性是非常复杂的，它是生产者、消费者多对多的一个场景，而且它是上下游结藕的异步链路，然后本身消息是一个有数据的状态，比如说消息有没有被消费者消费、是否消费成功、有没有定时结束等。
而且Tracing的消费链路是偶合了非常复杂的业务处理大马逻辑的，所以这个曲形呢对于这些排查过程中都，要解决这些非常复杂的一个链路的，所以Tracing在消息链路中要解决非常复杂的记录问题。针对于此，Rocket MQ 其实比一般的简单的sample MQ其实要更复杂，因为它有很多的一些业务类型，比如说事务、定时等，同时拥有非常复杂的一个客户端的状态，比如说push的消费者，其实有一个本地缓冲队列的状态，然后这里的信息也要记录清楚，因为不知道消息是否已经推到客户端，或者推到客户端之后是否在缓冲队列里面，还是已经开始进行业务处理。然后最重要的就是新的整个环境的需求，就是Tracing链路其实是需要更符合去开源的标准的需求，因为首先消息是异步解耦的，其实整个区域的Tracing链路数据，需要通过消息去连接上下游，进行一个列入闭环。整个的Tracing的数据格式，需要符合开源的open Telemetry 学习标准，这样才能被一些开源的系统所存储和展示。
三、Rocket MQ 5.0 Tracing 设计
第三部分讲解整个Tracing的链路设计要点，即考虑的问题、设计的目的、设计的好处等。
首先可以参照open Telemetry的Tracing 设计的标准，其实是一个个span的设计，比如说某一个请求就是一个span记录，每个span里面有很多属性和状态，它有几个基本的属性，比如说 start 时间和结束时间。然后就是请求的结果是成功还是失败，还可以添加自定义属性，比如说Rocket MQ 可以添加topic、groping、IP等属性添加进去。可以看到open Telemetry的标准里面其实在message领域里面定义了三个标准。
比如说send、receive、process，分别表示了发送、接收和处理消息三个span，但是在Rocket MQ 查询情况下，其实可以看到这里其实是一个事务消息，push的整个消费生命周期的时间轴，但除了这三个span的场景，还需要额外设计表达事物的一个状态的记录，还有一个push的本地在缓冲队列面的一个状态的记录，所以说在这个场景下Rocket MQ 设计的添加了两个span，其中有一个在commit队列里，另一个在await排队的队列，就是commit span可以设计事务提交的结果时间，此时提交之后，然后消息才能被ready，被消费者进行消费。
从commit 到consumer 的时候，其实有一个非常重要的在本地缓存队列的时间，这个时间加上之后，可以知道消息是否真的开始被消费，还是说一直在等待被实现的资源。
那么此时加上这个时间之后，真正的业务处理了process span，它的start与end 的时间，3点之后才是真正的消息处理耗时，这都是在各种消费者消费能力异常的情况下，自然需要await和await数据的精确排查定位。
总结来说，Tracing的链路设计，它其实是给予了open Telemetry领域的标准前提下，额外增加了Rocket MQ特殊的一些实践，然后receive和process做一些连接，这样整个消息的生命周期表达的更加清楚和清晰。然后对于各种非普通消息的消息类型做了更好的定位排查，其实这里是一个事务消息的距离，可能后续其实可以看到已经开源出去一些设计，同时可以看到还有一些定时的消息的设计，span 的设计和属性的设计。比如我们可以，比如Rocket MQ的特殊的span，属性设计其实有排查定位是非常需要用到的，比如说客户端的IP、生产者消费者user 的信息、还有资源的就是groping 、 consumer这些club IP等，以及各种关键的时刻数据、请求的结果，包括定时消息的绿色定时时间和实际定时结束时间等。
这些属性的设计都是基于各种各样的经验来设计的，并且能够完全定位且非常清晰的描述Rocket MQ的生命周期的各种请求情况。然后就是在这些各种span 设计为了增强平时定位排查的能力的情况下，同时全面接入了开源生态。
比如说将链路的Tracing ID通过 message 带到下游，并将这个信息一直传递下去，这样的话才能查到整个调用链路的完整信息，并且这个设计现在已经开源发布到open Telemetry社区的标准，pull request的编号为#6884以及#7091，欢迎大家去看PR，欢迎使用最新的Rocket MQ 5.0的Tracing客户端的记录，并可以提一些意见。
四、Rocket MQ 5.0 Tracing 最佳实践
接下来讲解可以用这些数据去做哪些事情，Tracing的数据其实最根本的一个需求是在出现问题的时候，能非常快速的去排查消息收发链路上的问题。整个数据的设计其实也是根据Rocket MQ的消息类型进行设计span和属性的设计。
第一点就是可以根据差错上的条件进行过滤Tracing的列入数据，比如说如何快速查出消费失败的消息的轨迹数据，其实就是查询条件process数据并且span等于fulse ，根据Tracing 的数据就可以进行查询;再比如说若处理时间长的条件去查询出处理时间长的链路的数据，其实相当于span 的process span的rt超过时间的多少决定的，哪些数据可以查询出来；或者说发送rt，可能那段时间网络会有问题，到底哪些消息会发送失败呢？
就是send 的rt大于多少值的时候，可以把这些轨迹的数据查询出来，所以定义了各种各样的一个问题之后，就可以非常方便的排查问题。比如说还可以举例，当少量的事务消息出现commit失败的情况，可以直接查询有span消息。在日常过程中，其实可能都是少量业务消息订单出现问题，其实可以根据topic 、group 以及本身消息里面的key查询出轨迹属性，继续排查这个消息是否投递正确、是否及时被投递以及投递至具体机器。
第二点就是对接了整个开源全链路的Tracing 标准之后，其实就是可以将调用链路的上下文通过生产者再通过消息载体再至消息下游，此时其实就会有一个Tracing 的ID，根据这个能够很快查出整个消息上下游以及整个调用电路的调用情况。第三点，对于一些高级用户，其实可能还有一些特殊的需求。
比如说经常接到的安全审计的需求，比如说在某个历史情况下还要查询出某个账号具体有哪些IP，访问调度过来的，在查询出所有的IP之后，可以看出哪些IP是属于非法IP；再如在访问某个topic的时候，需要知道曾经访问过此topic 的所有IP和账号，哪些账号曾经是一个非安全的账号，希望把所有的非安全账号针对的IP查询出来，其实是各种安全审计的需求。
五、Rocket MQ 5.0 商业版消息轨迹
其实再介绍一下，就是在这样各种各样新的消息轨迹的查询能力其实可以满足大家各种各样场景的排查需求。那么在整个Rocket MQ 5.0商业版的时候，Tracing 提供给大家使用的方法，首先Tracing 轨迹的功能展示给大家使用的，其实有非常强的检索能力，检索能力就是相当于之前提到的建立各种各样的索引去查询过滤所要的轨迹信息，那么其实它有一个非常强的检索能力，可以根据各种条件检索出所要的轨迹信息，然后还有最重要的一点是整个消息轨迹的记录，其实是免费全量提供了轨迹记录，其实这一点是非常难得的，因为整个用户其实应该知道一条消息的产生其实轨迹的信息数量比消息多很多，因为它其实是一对多消费的，每个消费者有各种各样的重复性的消费，所以它的轨迹数据量比本身消息本身的数量会多很多，再加上很多检索的索引的需求和成本，其实是成本非常大的，然后在做了各种各样的成本压缩之后，给用户提供到的就是全量的消息都会记录消息轨迹，并且免费提供给用户使用。
然后还有就是本身Tracing span的设计是一个非常复杂的，每个span之间可能有link 关系，可能是parent的关系，但本身复杂的关系过程中，其实使用开源的一些标准的通用展示页面去展示，其实是非常需要熟悉span设计的人才能看得懂，但是其实相当于针对消息 Rocket MQ 专门做的定制化的页面展示，若这是一条消息的整个生产和消费的情况，那么可以看到一条消息发送了几次、其中有几次发送成功、然后定时消息的状态、有没有定时结束、被哪些group消费，每个group消费之后，其实总共投递了几次，在客户端是什么时候投递到的、处理耗时是多久，然后这个处理的结果是多少。这个特殊化的定制页面展示对于用户来说其实就是非常友好的。
然后若有兴趣可以查看一下开源到社区之中的pr的详情，现在已经全量发布了，就是有两个pr，开源了整个 Rocket MQ Tracing 的设计，欢迎大家使用新的 Rocket MQ 5.0的消息轨迹的open Telemetry社区或者是轨迹的客户端来体验整个新型的消息轨迹。
