大家好,我是蓝胖子,随着微服务的普及,在面对日益复杂的架构和请求链路时,链路追踪技术就显得更加重要,今天我们花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都有其状态值,分别是
Unset
Error
Ok
显示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的规范。但是它们都会有传播者这个概念,只是各自的实现和遵循的协议不同。