深入可观测底层:OpenTelemetry 链路传递核心原理

本文涉及的产品
可观测可视化 Grafana 版,10个用户账号 1个月
简介: 本文会系统讲解链路传递一些基本概念,同时结合案例讲解链路传递的过程。

Context、Propagator 的概念

我们先看一张在 HTTP 通信下,进行链路传播的例子。

image.png

图中是一个 Client 请求 Server 通信,同时 Client 把自己的链路信息传递给 Server 的过程

可以看到,链路信息通过一个叫 TraceContext 对象封装起来,通过 Http Headers

来存取这个对象,最后达到传播的效果,这里面 TraceContext 就是一个 Context 上下文对象。

Context 是一种传播机制,它跨越 API 边界,在逻辑执行单元间传递执行范围的值。链路追踪系统在系统进程内部,进程间通过共享进程的 Context 上下文 对象传递链路信息。

刚才 Http Headers 起到了一个传递 Context 载体作用,在链路追踪系统,我们把这样的载体统称为 Propagators。上面传递过程我们用另一张图看看 Propagators 和 Context 的关系:

image.png

什么是 Propagator?OpenTelemetry 是这样定义的

Cross-cutting concerns send their state to the next process using Propagators, which are defined as objects used to read and write context data to and from messages exchanged by the applications.

大概意思,横切关注点通过它,在进程间进行状态的传递。这里,又牵涉了一个重要的知识点。

Cross-cutting concerns 的概念

关注点:如果系统按功能划分,关注点就是系统的核心功能。 横切关注点:从整个系统横向维度看到的核心功能。比如日志功能就是横切关注点的一个典型案例。日志功能往往横跨系统中的每个业务模块。图可能比文字来得更形象:

image.png

横切关注点(系统基本功能)通过 Propagator 可以传递它的状态给下一个进程,Propagator 是通过应用程序读写上下文数据进行数据的交换。 每个关注点都包含了一组 Propagator Propagator 把每一个横切关注点通过上下文去 Injection 注入和 Extract 提取。

链路传递一般通过特定的请求拦截器库来实现,拦截器通过拦截输入和输出请求,利用对 Propagator 的注入和提取操作来实现传递。

Propagator API 用户可以通过检测库来实现 Propagator 操作的 API。

Baggage 链路传递初探

在一个链路追踪过程中,我们一般会有多个 Span 操作, 为了把调用链状态在 Span 中传递下去,期望最终保存下来,比如打入日志、保存到数据库。SpanContext 会封装一个键值对集合,我们叫它Baggage .

Baggage 会在一条追踪链路上的所有 Span 内全局传输。原理是上一个 Span 将 Context 中 Baggage 注入到 Propagator ,Propagator 和目的 Span 联系,从 Propagator 提取出Baggage ,再写入到目的 Span 的 Context 中。

OpenTelemetry 中关于 Baggage 原文定义:

Baggage is used to annotate telemetry, adding context and information to metrics, traces, and logs. It is a set of name/value pairs describing user-defined properties.

通过 Baggage 我们可以实现强大的追踪功能。例如:在用户的手机端添加一个 Baggage 元素,并通过层层服务调用,传递到最后数据库的操作。有了 Baggage,如果我想定位请求中消耗很大的 SQL 语句是来自于具体哪个手机端用户从 Trace 中一看便知。反过来,我们可以知道一个手机端用户它依次做了哪些 SQL 语句查询。这比你登录服务器一台台找前端、后端日志,还要把他们关联起来分析,要容易很多。

方便理解,我们演示 Baggage 效果:

首先,我们在 loadBalancer 请求中加一个 Baggage,loadBalancer 请求了 resource 服务:

image.png

然后我们从 resource 服务中获取 Baggage 信息,并把它存储到 Span 的 Attributes 中:

image.png

最终,我们从跟踪系统的链路 UI 中点击 resource 这个 Span,找到传递的 Baggage 信息:

image.png

当然,Baggage 拥有强大功能,也会有很大的消耗。由于 Baggage 的全局传输,每个键值都会被拷贝到每一个本地(local)及远程的子 Span,如果包含的数量量太大,或者元素太多,它将降低系统的吞吐量或增加 RPC 的延迟。

Tag 链路标签和业务监控

我们进行系统链路追踪,除了 Trace 本身自带信息,如果我们还希望添加自己关注的监控。Trace 支持用打标签 Tags 方式来实现。Tags 本质还是 Span 的 Attributes(在 OpenTelemetry 定义中,统称 Attributes。在 Prometheus、Jaeger 里面沿袭 Tags 老的叫法)。

打 Tags 的过程,其实就是在 Span 添加我们自定义的 Attributes 信息,这些 Tags 大部分和我们业务息息相关,为了更方便做业务监控、分析业务。

我们看一个 Java 打 Tags 的例子:页面定义好了一个 Tag,名字叫"username"。我们输入 Tags 的值,然后把 Tags 通过一个 HTTP 请求发送给付账单的 API,

image.png

图六:打 Tags 的演示

API 获取 Tags 后,把它保存到当前 Span 的 Attribute 中。这个 Span 对应的是代码里面的一个 gateway 方法, 如果不重名 Span 名称,默认使用 gateway 作为 Span 名称:

image.png

打了 Tags 后,我们可以在跟踪系统搜索 Tag 关键字。通过 Tag 可以快速找到对应的 Trace:

image.png

图七:基于 Tags 的搜索

可以看到,根据 Tags 的 key 我们可以很方便筛选想要的 Span 信息。实际场景里,我们面临是从成千上万链路中快速定位访问异常的请求。打 Tags 对我们诊断程序非常有帮助。

我们从 Trace 中找到相应的 Span,能看到 Tag 已经注入到 gateway 的 Span 中:

image.png

图八:Tags 的用法

Baggage 和 Span Tags 的区别

Baggage 在全局范围内,(伴随业务系统的调用)在所有 Span 间传输数据。Tags 不会进行传输,因为他们不会被子级的 Span 继承;

Span 的 Tags 可以用来记录业务相关的数据,并存储于追踪系统中。

Event 事件 监控更细微的链路行为

一个 Span 下可以添加多个事件,事件是相对于 Span 更小的操作粒度。在我们想知道一个 Span 内各种操作,这种操作期望在监控平台能够分析,Event 就可以满足需求。

比如请求一个商品结算的 API,这个 API 调用商品结算方法 Count,Count 里面分别做了查询商品库存,核实商品价格,结算总价这几个步骤,商品库存还是由几次数据库的 SQL 查询聚合的结果。如果这个 API 有异常,查看商品结算这个 Span 往往远远不够,在真实的线上场景,我们还需要追踪每个步骤的请求状态和详细日志。

事件和 Span 的数据结构类似,包含的基本属性:

事件名称;

事件时间:它支持由开发者自定义添加时间,让事件时间更精准;

属性 Attributes:和 Span 一样,用来记录事件相关信息。
image.png

我们添加 Event 后,从链路中看到 Event 信息记录在 Trace Logs 中。在事件中,我们还能添加相关 Attributes ,记录事件某些信息:

image.png

OpenTelemetry 链路数据如何传播

Carrier 和 Propagator 的关系

在 OpenTelemetry 中,Trace 的传递中有一个核心的概念,叫 Carrier(搬运工具)。它是 Propagator 用来读取 Context 数据的一种媒介 medium,Carrier 数据格式可能是一个字符 Map 或者一个字符数组。

Carrier 充当"搬运" Span 中 SpanContext 工具。例如 OpenTelemetry 中为了把 Trace 的 Span 信息传递下去,在 HTTP 调用场景中,会有 HttpCarrier,在 RPC 的调用场景中会有 RpcCarrier 来搬运 SpanContext。Trace 通过 Carrier 可以把链路追踪状态在进程中、进程间传递。

数据传播基本操作

回顾刚才一些概念,我们完整描述下 OpenTelemetry Span 在传播中有的基本步骤:

StartSpan:Trace 在具体操作中自动生成一个 Span

Inject 注入: 将 Span 的 SpanContext 写入到 Carrier 的过程

链路数据为了进行网络传输,需要数据进行序列化和反序列化。这个过程 Trace 通过一个负责数据序列化反序列化上下文的 Formatter 接口实现的。例如在 HttpCarrier 使用中通常就会有一个对应的 HttpFormatter。所以 Inject 注入是委托给 Formatter 将 SpanContext 进行序列化写入 Carrier。

Formatter 提供不同场景序列化的数据格式,叫做 Format 描述。比如:

TextMap: 基于字符串的 Map 记录 SpanContext 信息,适用 RPC 网络传输

HTTP Headers: 方便解析 HTTP Headers 信息,用于 HTTP 传输

一个 Python 程序实现 Inject 注入过程,Formatter 序列化 SpanContext 成 Text Map 格式:

image.png

Extract 提取: 将 SpanContext 从 Carrier 中 Extract(提取出来):

image.png

同理,从 Carrier 提取的过程也需要委托 Formatter 将 SpanContext 反序列化。

运行原理

image.png

图一:链路数据在 HTTP 传递

我们基于 HTTP 通信解释传播原理。由图一,这个过程大致分为两步:

1、发送端将 SpanContext 注入到请求中,相应伪代码实现:

image.png

2、接收端从请求中解析出 SpanContext,相应伪代码实现:

image.png

Carrier 负责将追踪状态从一个进程"Carry"(搬运)到另一个进程。对于一个 Carrier,如果已经被 Injected,那么它也可以被 Extracted(提取),从而得到一个 SpanContext 实例。这个 SpanContext 代表着被 Injected 到 Carrier 的信息。

说到这里,你可能想知道这个 Carrier 在 HTTP 中具体在哪。其实它就保存到 HTTP 的 Headers 中。而且,W3C 组织为 HTTP 支持链路追踪专门在 Headers 中定义了 Trace 标准:

https://www.w3.org/TR/trace-context/#trace-context-http-headers-format

W3C 组织是对网络标准制定的一个非盈利组织,W3C 是万维网联盟的缩写,像 HTML、XHTML、CSS、XML 的标准就是由 W3C 来定制

跨进程间传播数据

数据传播按照场景分为两类:进程内传播、跨进程间传播 Cross-Process-Tracing。

进程内传播是指 Trace 在一个服务内部传递,监控了服务内部相互调用情况,相当比较简单。追踪系统最困难的部分就是在分布式的应用环境下保持追踪的正常工作。任何一个追踪系统,都需要理解多个跨进程调用间的因果关系,无论他们是通过 RPC 框架、发布-订阅机制、通用消息队列、HTTP 请求调用、UDP 传输或者其他传输模式。所以业界谈起 Tracing 技术 往往说的是跨进程间的分布式链路追踪(Distrubute Tracing)。

我们用 OpenTelemetry 实践一个 HTTP 通信的 Trace 例子:

这是一个 Java 程序,我们向下游服务发起一个 HTTP 请求。

程序中使用 OpenTelemetry 的 inject 注入,通过 HTTP Headers 把 Trace 传递给 127.0.0.1:8080 的服务。传播前,手动还创建两个想要一块传播的 Attributes:

image.png

运行程序,从监控平台我们看到,Trace 从一个程序成功传递到了 127.0.0.1:8080 的服务:

image.png

跨进程传播数据

Github 中文文档

我们 OpenTelemetry Github 社区对链路传播中文介绍,目前还在逐步完善当中。也欢迎大家去贡献更多的中文内容。

Propagator 介绍

https://github.com/open-telemetry/docs-cn/blob/main/specification/context/api-propagators.md

Context 介绍

https://github.com/open-telemetry/docs-cn/blob/main/specification/context/context.md

Baggage 介绍

https://github.com/open-telemetry/docs-cn/blob/main/specification/baggage/api.md

作者介绍

蒋志伟,爱好技术的架构师,先后就职于阿里、Qunar、美团,前 pmcaffCTO,目前 OpenTelemetry 中国社区发起人。

欢迎关注我们的 Github 项目:https://github.com/open-telemetry/docs-cn

欢迎大家关注“OpenTelemetry”公众号,这是中国区唯一官方技术公众号。

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
15天前
|
运维 监控 Cloud Native
|
存储 监控 Java
一篇文章带你搞懂SkyWalking调用链追踪框架
介绍了Skywalking的作用,安装方法,架构设计等等
一篇文章带你搞懂SkyWalking调用链追踪框架
|
15天前
|
存储 Web App开发 运维
原来10张图就可以搞懂分布式链路追踪系统原理
原来10张图就可以搞懂分布式链路追踪系统原理
|
运维 监控 数据可视化
可观测性和传统监控的三大区别
可观测性和传统监控的三大区别
410 0
《“静态调用链路发现“在APM中的应用场景分析及实践探索》电子版地址
“静态调用链路发现“在APM中的应用场景分析及实践探索
61 0
《“静态调用链路发现“在APM中的应用场景分析及实践探索》电子版地址
|
存储 消息中间件 运维
一文详解|Go 分布式链路追踪实现原理
在分布式、微服务架构下,应用一个请求往往贯穿多个分布式服务,这给应用的故障排查、性能优化带来新的挑战。分布式链路追踪作为解决分布式应用可观测问题的重要技术,愈发成为分布式应用不可缺少的基础设施。本文将详细介绍分布式链路的核心概念、架构原理和相关开源标准协议,并分享我们在实现无侵入 Go 采集 Sdk 方面的一些实践。
1337 0
一文详解|Go 分布式链路追踪实现原理
|
存储 缓存 运维
调用链追踪系统在伴鱼:OpenTelemetry 最佳实践案例分享
在 理论篇 中,我们介绍了伴鱼在调用链追踪领域的调研工作,本篇继续介绍伴鱼的调用链追踪实践。在正式介绍前,简单交代一下背景:2015 年,在伴鱼服务端起步之时,技术团队就做出统一使用 Go 语言的决定。
644 0
调用链追踪系统在伴鱼:OpenTelemetry 最佳实践案例分享
|
数据采集 存储 监控
如何理解分布式链路追踪技术
什么是链路追踪?微服务引发了怎样的问题?
293 0
如何理解分布式链路追踪技术
|
存储 JSON 监控
分布式链路追踪框架架的基本实现原理
分布式链路追踪框架架的基本实现原理
208 0
分布式链路追踪框架架的基本实现原理
|
Java
核心链路方案
核心链路方案
220 0