大家好，我是蓝胖子，随着微服务的普及，在面对日益复杂的架构和请求链路时，链路追踪技术就显得更加重要，今天我们花5分钟的时间，来掌握和链路追踪相关的基本概念。不会涉及到具体的技术框架和落地，本文主要是对链路追踪中涉及的专业术语做一个简短的介绍。
不同链路追踪的SDK可能对相关的专业术语有不同的称谓，但它们所代表的含义和内容基本一致。
trace
trace 指完整的一条请求链路。有时也指在某个组件内的一条完整链路。
span
span可以理解成链路追踪过程中的一个小的阶段，通常span会有如下的一些信息
- span context
- event(logs)
- tag(attribute)
- status
- kind
我们来依次看下它们代表什么含义，
span context
指span的上下文信息，通过在不同进程间传递这个上下文信息，能够将不同进程的链路拥有串联在一起。通过span context会包含trace id(一条完整的链路拥有一个唯一的trace id) 和span id(一个span拥有的唯一id)。
event(logs)
event记录 一个小阶段span中某些特别的时间点事件， 有时也在某些Trace相关的SDK中称为log，类似与下面的代码进行设置
go
span.AddEvent("test",
trace.WithStackTrace(true),
trace.WithTimestamp(time.Now()))记录的时候可以将程序的堆栈和时间戳同时记录下来。
tag(attribute)
span可以设置键值对，被称作为span打上标签tag，有时也被成为span的属性attribute
status
openTelemetry SDK规定每个span都有其状态值，分别是
UnsetErrorOk显示trace数据的组件库在解析到这些状态值时会有不同的显示，默认是unset，为unset时表示链路追踪过程没有错误，为Error时则表示有错误发生，一般情况下不需要显示设置Ok状态，设置ok状态说明是开发人员显示的设置为成功状态。
status本质上就是设置span的attribute，比如我们通过OpenTelemetry SDK如下代码设置status时
go
span.SetStatus(codes.Error, "fail")最终是设置了3个属性键值对
设置为错误的span在jaeger上还未有醒目的标记
status这个改变可能在使用其他trace 相关的SDK时是没有的，比如OpenTracing 规范中没有提及这个概念。
kind
kind本质上也是为span设置键值对属性，同样它也是OpenTemetry SDK规定的，其他trace相关的SDK可能没有。
创建 Span 时，它是 Client、Server、Internal、Producer 或 Consumer 之一。根据 OpenTelemetry 规范，服务器 Span 的父级通常是远程客户端 Span，客户端 Span 的子级通常是服务器 Span。类似地，消费者 Span 的父级始终是生产者，生产者 Span 的子级始终是消费者。如果未提供，则假定跨度类型是内部的。
其实kind和status的设置并不是强制的，都是起到提示的作用，为了更好的区分链路数据各个span之间的关系或者标记span。
baggage
因为链路追踪涉及到跨进程，当想把前一个进程的某些信息随着传递trace 上下文时传递给后一个进程，那么就要用到baggage，baggage是一种标准(协议)，提供了一种统一的方式来存储和传播信息。
w3c规定了baggage的协议格式 www.w3.org/TR/baggage/.
也就是说只要客户端和服务端都按上述的协议封装和解析，那么对端就能解析出baggage中的信息。
propagator
传播者propagator 负责将刚才提到的span context和 baggage 传递到下个进程中，同时它也具有解析其他进程传递过来的span context和 baggage的功能。
这里会涉及到进程间传递信息的具体方式，w3c也规定了在http中传递span context的方式，在http头部设置固定的和trace相关的请求头，对端也必须从这些请求头来解析trace数据。
propagator 是遵循span context 和baggage 数据传递规范的具体实现。
注意, 在跨进程传递时，并不是每种trace SDK都是遵循W3C规范的，比如zipkin 的SDK在跨进程传递trace数据时，使用的http请求头就和W3C规定的不同，而OpenTelemetry SDK 则是完全遵循了W3C的规范。但是它们都会有传播者这个概念，只是各自的实现和遵循的协议不同。