开发者学堂课程【可观测能力升级系列课程： Tracing 链路追踪】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1224/detail/18310
Tracing 链路追踪
内容介绍：
一、5.0和4.0的区别
二、tracing 的背景和需求
三、tracing 的实践
四、tracing 的设计
今天给大家介绍rocket mq 5.0可观测系列tracing 链路追踪的部分，主要分四个部分，第一部分讲一下5.0和4.0相比可观测部分全面提升的哪一些东西，第二部分讲一下tracing 链路追踪背景和一些需求，第三部分讲一下5.0tracing设计的一些要点，第四部分讲了5.0 tracing的数据给我们带来可有哪些最佳的一些实践。
一、5.0与4.0的区别
5.0的可观测的能力做了全面的提升，然后metrics tracing logging 方面都做了提升后续还会补齐event的事件，帮助大家定作为事件排查，这些事件的一些提升其实主要是两个方面，一个是沉淀云上多年的一些问题定位排查，帮客户排查各种各样复杂的业务场景问题，积累下的一些经验，特别设计的一些观测的一些数据，有一些metrics tracing一些推荐的数据，推出了全新的一套指标，这套指标它是全面拥抱的开源的生态，符合开源的生态的一些标准的，比如说metrics 数据它是符合普罗米修斯的一些标准数据，涵盖了各种各样一些消费场景的特殊的数据需求，为用户提供了一些国外最佳的一些大款的模板，tracing数据上其实是做了一个比较大的改变，原来是用消息来实施的自定义的一些tracing格式的实现，然后现在就是要对接整个的一个标准的opentelemetry生态，将这个的数据符合开源生态的标准，让用户能够将这个数据对接到开元的一些系统上，并且能够连接消息上游和下游tracing一个据链路，目前tracing 链路新的一个标准已经开源到了opentelemetry社区网络，logging做了更多的一些标准化格式化的处理，比如说标准全统一的error code处理，error message的完整性的排出和完整的格式化的梳理，那么新增的event事件，其实也是就在我们日常的过程中可以发现是非常需要事件来帮助与排查定位的，比如说一些电源变更，消费者上下线，容器重启等等，event事件是可以帮助定位排查的。
二、tracing 的背景和需求
1. 复杂性
现在展开讲一下tracing的一些部分的一些东西，本身推进在消息上面来说，它其实是一个比较复杂同步分的，因为消息的电路性是非常复杂的，它是一个生产者，消费者多对多的一个场景，而且它是上下有解耦的一个异步联络，本身消息是一个有数据的状态，比如说消息有没有被消费者消费，是否消费成功，有没有定时结束等等，而且消费链路是偶合了非常复杂的业务处理代码逻辑，所以tracing需要解决一些非常复杂的排查链路的记录问题。
2. 特殊性
这个缺陷，对于这些排查过程中都要解决非常复杂的一个链路的记录问题，针对对比一般的一个简单的tracing，它要更复杂，因为它有很多的一些业务类型，比如说事物啊，定时等等，他还有非常复杂的一个客户端的状态，比如说push consumer的那个消费者，他其实也有一个本地缓冲队列的一个状态，这个信息也要记录清楚，因为不知道消息是否是推到客户端，推到客户端之后是否在缓冲队列里面，还是已经开始进行业务处理了，然后最重要就是我们新的一个整个环境的一个需求就是tracing 链路其实是需要更符合去开源的一个标准的一个需求，因为首先消息是异部解耦的，整个消息的全链路数据，需要通过消息去连接上下游，进行一个链路路闭环，整个的数据格式，它需要符合开源的一个opentelementry标准学习标准，才能被一些开源的一些系统所存储和展示。
3.tracing 的设计
下一部分，讲整个tracing的链路设计的一个要点，就是怎么考虑的，为什么要这么设计？这么设计会带来什么好处？
首先可以知道，参照OPPO开发区的一个缺点设计的标准，它其实是有一个设计在里面，比如说某一个请求就是单个记录，那每个里面它有很多属性和状态，它有几个基本的属性，比如说开始时间和他结束时间，sattas是这个请求的一个结果是成功还是失败，还可以添加我们自定义属性，比如说我们可以添加topic，consummer group，还有IP，等等各种各样的属性添加进去，可以看到他在领域里面定义了三个必须的span，黄色的send receive process ，分别表示了发送 接收 和 处理消息三个时间段，但是在rocket mq情况下，其实可以看到这其实是一个事务消息的时间轴，除了这个三个spen的情况，还设计了额外区设计表达事物的一个状态记录，还有本地push许可在缓冲队列里的一个状态的记录，在这个场景下像rocket mq的额外添加的俩个span，commit 事务提交的span，和一个在缓冲队列里面等待排队的await的span，但是commit span可以设计事务提交的结果时间，时间提交之后，才能被消费者消费，其实有一个非常重要的在本地缓存队列的时间，这个时间加上之后，可以消息是否可以被消费，还是说一直等待在被消费的await资源，那么真正的process业务处理的时间加上这个spend的时间，三者相加之后才是真正消息处理的耗时，这都是在各种消费者消费的消费能力异常的情况下，需要这个await的精确数据的定位，那么总结可以看到，tracing 的电路设计，他其实是基于open telemetry社区的标准前提下，额外增加了rocketmq特殊的一些span，这些send和receive做一些连接，这样消息的生命周期表表达的更加清晰，对于非普通消息的消息类型，做了更好的定位排查，这里是事务的消息的举例，后续还有一个定时消息的span设计和属性设计，比如span设计不仅定义了rocket mq的send recieve ，定义了更多rocket mq的span数据，在属性设计，其实有排查定位，有需要用到的客户端的IP，还有各种消费者的优势信息，还有各种关键的时刻数据，还有请求的结果，预设时间的设计等等，这些属性设计其实是基于各种经验来设计的，并且可以非常清晰地定位和描述rocketmq一种消息的请求情况，那么还有就是这些span的设计，全面接入了开源生态，比如说可以通过链路的tracing的信息传输到下游链路，再通过receive传输下去，这样才能查到整个调用链路的完整信息，并且这个开源设计已经发布到opentelemetry社区，add pull编号为6884和7094，欢迎使用最新的5.0的tracing的记录，并提一些意见。
三、Tracing 的实践
利用这些数据可以做些什么？Tracing的数据首先一点，也是最根本的需求，即在出现问题时，可以最快速的去排查出消息收发链路的一些问题整个的数据设计，也是根据数据的消息类型和rocket mq的span设计。
所以Tracing的消息收发问题排查场景，第一是根据差错条件过滤出所需要的tracing链路数据，比如说怎么能快速查出消费失败的一些数据，查询条件就是process的span数据，并且statas的false，用tracing的数据就可以查出，比如说能根据特别处理时间长的一些一些条件去查出这些处理时间长的一些数据，那就是其实相当于span，比如说rt超过多少时间，那些数据到底有哪些可以去大力捞出来？或者是说发送的那段时间，网络会有问题，那到底哪些消息会发送失败呢，send大于多少时，可以把这些轨迹的的数据查出来，所以说这些定义了各种各样的一个问题之后，可以非常方便的排查问题，比如说还可以举例，比如说事物消息是哪些事物消息，少量的事物消息commit 失败的情况。比如说有commit有失败的情况，通过roback的使用去查询。
四、Tracing 的设计
那么还有是其实在日常过程中，其实第二个是可能是少数的一些业务消息出问题，比如说我们某个订单的消息出了问题，那我们其实我们可以根据topic group 的key去查询出要的一些轨迹属性去继续排查这个消息是否投递正确，是否及时被投递，并且投递到哪台机器上面，那么还就是对接了整个开源那个产权电路，这个确定标准之后，可以将调用链路的上下文通过生产者，再通过消息载体带到下游的消费者。
这个时候就会有一个标准的tracing ID，我们根据tracing ID很快的查出整个调用链路的调用情况，那么还有一些高级用户，可能还有一些特殊的一些需求，比如说经常接到的一些安全审计的需求，比如说在某个历史情况下，还要查出某个加号到底是有哪些IP和访问调度过来的那些，其中当初所有的IP之后，能可以看出是这些哪些IP是属于非法ip，那么还有比如说是在访问某个topic的时候，需要知道这些曾经访问过这个topic的所有IP和账号。哪些账号其实已经是非安全的账号，希望把这些非安全账号针对的IP所有的能够找出来，其实是各种全种安全审计的需求。
在这样的一个各种各样新的消息轨迹的能力，其实可以提供大家各种各样的满足，各种各样的场景的排查的需求，那么在整个mq5.0商业版的时候，tracing 是怎么样提供给大家使用呢，首先tracing轨迹的一个功能展示给大家使用，它是有一种非常强的解锁能力，就是相当于之前比如说我们各种各样前面提到的，需要各种索引建立去查询过滤所要的一些轨迹信息，那么有一个非常强的检索能力，他可以更根据各种条件去结合出我们所要的轨迹信息，然后还有最重要的是整个消息轨迹的记录，它其实是免费全量提供了一个轨迹记录，这1点是非常难得的，因为整个用户其实应该知道一条消息的产生，轨迹的信息数量本身比消息本身的那个数据量要多非常多，因为首先它其实是一对多消费，那每个消费者他是有合作各种各样的重复的性的一个消费，所以说它的轨迹数据量比本身相信本身的数量会多很多，再加上很多解锁的索引一些需求和成本，它其实是成本非常大的，做各种各样的一个成本压缩之后，我们给用户提供到了重要的消息，都会记录消息轨迹，免费提供给用户使用。本身tracing 的span的设计，它是非常复杂的，每个span之间它可能是有link关系，复杂的关系过程中其实用开源了一些标准的通用的一个展示页面去展示，是要非常熟悉这个span设计的一个人才能看得懂。
但是针对rocketmq的消息场景之后，专门定制了一个消息页面展示的场景，大家可以看到下面是一条比较详细的整个生产和消费的情况，发送了几条消息，有哪些消息发送成功，定时的历史消息还有哪些没有定时结束，还有哪些被消费，每款消费点开之后，总共投递了四处，在客户端是什么时候投递到的，耗时多久，这个可视化的定于也面对用户来说是非常友好的，以上就是设计的全部。
有兴趣可以看开源到opentelementry社区的pr的详情，现已经全部发布，现在有俩个pr开源。
欢迎大家使用新的5.0的消息轨迹的open telemetry的过程客户端轨迹，来体验新的消息轨迹。
