观测利器：让天下没有难懂的 Trace

date

Sep 4, 2023

slug

trace-diagrams

status

Published

什么是 Traces ?

这两年可观测领域受到了比较多的关注，其中以 Traces 尤为突出。那么什么是 Traces 呢？它又能做什么呢？我们来看看官方给予的定义：

Traces give us the big picture of what happens when a request is made to an application

简单来说：Traces 能 描绘 一个请求在应用中究竟做了什么。

描绘？

对于原始的 Traces 数据而言，与其说是“描绘”，不如说是“描述”：应用做的事情被拆解成一个个小的单元（Span），多个有着父子关系的 Span 组成一个完整的 Trace。尽管它的数据详尽——包括属性（attributes）、事件（Events）、上下文（Context）等内容，但是最大问题也很明显：不够直观，有效信息获取效率低。

{
	"name": "hello-greetings",
	"context": {
		"trace_id": "0x5b8aa5a2d2c872e8321cf37308d69df2",
		"span_id": "0x5fb397be34d26b51"
	},
	"parent_id": "0x051581bf3cb55c13",
	"start_time": "2022-04-29T18:52:58.114304Z",
	"end_time": "2022-04-29T22:52:58.114561Z",
	"attributes": {
		"http.route": "some_route1"
	},
	"events": [
		{
			"name": "hey there!",
			"timestamp": "2022-04-29T18:52:58.114561Z",
			"attributes": {
				"event_attributes": 1
			}
		}
	]
}

所以更多维、更直观的图表就显得尤为必要了。

各种变换形态

首先，我们需要将 Traces 数据抽象成一棵多叉树。

在这棵多叉树的各个节点信息中，藏着 Trace 的多个维度信息：

Span 之间的调用关系：parent_id 指向调用它的父级节点

Span 调用的时序关系： start_time & end_time 表明了 Span 的开始结束时间点

Span 耗时： elapsed_time 代表该 Span 的耗时

Timeline 时间线图

首先，我们通过「Timeline 图」（a.k.a 瀑布图）纵览所有 Span 之间的父子关系、时序、耗时。

在时间线图中，你可以掌握单个 Trace 的全部信息：

查看所有的 Span 概况，按照服务进行颜色区分，同时展示所有的父子关系。

通过时间轴和线条的长度判断出 Span 具体耗时。

点击 Span 可以查看其详细信息，包括标签和进程等所有上报信息。

虽然它全能，但在一些具体维度上仍旧不够直观，所以我们要在这棵多叉树上进行精加工：

Span 之间的父子关系 → 拓扑图

以接口、服务等维度汇聚统计信息 → 表格统计

Span 调用的时序 → 时序图

Span 耗时分布 → 火焰图

下面就来分享一下相关图表的展示逻辑细节。

拓扑图

对于拓扑图而言，它将主要的重点放在了 Span 之间的关系上，你可以很清晰地获取到 Trace 的调用关系、层级等信息，但同时它也刻意忽略了时序信息，下面会有较多场景会提到这一点。

表格统计

表格统计的重点是，将 Trace 中的汇聚信息平铺展示出来。这里有两个需要额外解释的概念：接口&服务。

接口和服务

【接口】的内容实际上就是 span_name —— 操作名称的别名。而【服务】则是来自于 resource.service_name ，表明该 Span 所属的服务，以简单的名字字符串作为 Trace 维度的唯一标识。

时序图

时序图，顾名思义，主要是想突出 Trace 的时序特性。

这是一种 UML 行为图，我们将它原本的几种元素结合 Trace 场景做了一个概念转换：

物件（Object）和生命线（Lifeline）用一个 方框+垂直线条 来共同表示 接口或服务在 Trace 流程中的生命周期。

讯息（Message）用一条 水平带箭头的连线 表示 接口或服务之间的调用，也就是 Span 的主要体现形式。

活化（Activation）：用一个 垂直方向的矩形 表示 接口或服务的耗时区间，它并不精确，但能表达出不同 Span 的耗时前后时序关系。

此外，时序图有一些额外封装和添加的概念，下面我们会一一展开解释。

服务接口聚合

首先是对服务聚合的概念阐释，和时间线图类似，我们会从 resource.service_name 字段中抽取所有 Span 共有的服务概念。额外地，我们从 attributes 字段中的信息尝试判断当前 Span 的形态，将不同的场景做一个简单区分。如图所示， service_foo 服务中会区分出 api/* 和 mysql 两种接口，它可以让你更好地了解不同组件之间的调用关系。

相对时序

与时间线图不同的是，时序图为了表达服务与服务之间的调用关系，默认采用了“相对时序”，而非严格按照 start_time 排序的“绝对时序”。

绝对时序：所有线条都按照 span 的绝对发生时间绘制，淡化父子关系

相对时序：父子的关系优先于绝对时间，同一个父节点下的 span 有绝对的先后顺序，不同父节点下的 span 不保证其绘制的先后顺序

我们举一个更容易理解的例子：假设某一个 Trace 有5个 Span，s1 → s5。s2 是 s3 的父节点，s4 是 s5 的父节点。先按照“绝对时序”画出时序图：

虽然它严格遵循了“时序”，但是原本的父子关系被淡化了，仅从图中基本没法判断出 s2 & s3 \ s4 & s5 之间有什么联系（图中的 t 是为了展示额外添加的，真实数据中不存在）。

我们再按照“相对时序”来绘制：

可以看到，虽然我们稍微“牺牲”了一些时序上的绝对性，但是调用之间的关系更清晰了，用户更容易在庞大的图表中找到调用关系。

虚拟的开始节点

在图中有两个内容是“虚拟”出来的：开始节点和返回虚线。

当时序上的第一个 Span（通常是根 Span）的类型是被调或异步被调时，为了表示该特性我们会在图的最左侧补充上一个虚拟的 Start ，它没有其他实际意义，只是表达整个追踪的“开始”节点。

调用返回

第二个添加的虚拟内容就是返回虚线。

为了更加准确地表达 Span 在时序上的流入流出状态，我们会根据 Span 中的 end_time 生成的一个虚拟调用返回，同时开启一个时序图的 Activation ，用来做 Span 耗时的示意。需要注意的是：它并不是在所有的请求中都会开启，当且仅当 Span 的调用类型是主调。

主调被调合并

当父 Span 是主调，子 Span 是被调时，我们会把两个 Span 的信息合并到同一个 Message 中。

火焰图

火焰图最早是用在 CPU 性能分析领域，最大的特点是形似火焰，CPU 耗时越大在图中展示的元素越宽，开发者可以通过寻找“平顶山”来确定性能瓶颈。

原始的局限

火焰图最大的局限在于无法精准地展示 Trace 中的 Span “并行”的概念，即使已经有无数“前者”在尝试了。

原始火焰图更多用在 Profiling 场景下，此时对于程序函数调用栈关系的可视度有着更高的要求——即对于 Y 轴信息的准确程度。但是对于 Trace 而言，Span 的执行时间长度、顺序在展示上的优先级更高。所以，在 Trace 领域我们采用了一种火焰图的变体—— FlameChart。它最早来自 Google Chrome 的 Web Inspector：