Go微服务框架go-kratos中如何实现OpenTelemetry的分布式链路追踪？
- 内容介绍
- 文章标签
- 相关推荐
本文共计1891个文字，预计阅读时间需要8分钟。
分布式链路追踪简介
1. 分布式链路追踪介绍分布式链路追踪是一种用于监控分布式系统中服务间调用关系的技术。它能够帮助开发者了解请求在系统中的流转路径，从而快速定位和解决问题。
2. 分布式链路追踪概述关于分布式链路追踪的详细介绍，您可以查看我之前发布的文章。同时，我还分享了一篇关于微服务架构学习与思考的文章（09）：分布式链路追踪系统 - Dapper论文学习（https://www.cnb.com）。
一、分布式链路追踪发展简介 1.1 分布式链路追踪介绍关于分布式链路追踪的介绍，可以查看我前面的文章 微服务架构学习与思考(09)：分布式链路追踪系统-dapper论文学习(www.cnblogs.com/jiujuan/p/16097314.html) 。
这里的 OpenTelemetry 有一段发展历程。
APM(Application Performance Monitoring) 和 Distributed Tracing(分布式跟踪)，后者是前者的子集。
微服务架构流行起来后，为了监控和定位微服务中请求链路过长导致的定位和监控问题，分布链路监控也蓬勃发展起来。出现了
很多有名的产品，比如：Jaeger，Pinpoint，Zipkin，Skywalking 等等。这里有个问题，就是每家都有自己的一套数据采集标准和SDK。
为了统一这些标准，国外的人们就创建了 OpenTracing 和 OpenCensus 2 个标准。最先出现的是 OpenTracing。为了统一标准，后来两者合并为 OpenTelemetry。
1.2 OpenTracingOpenTracing 制定了一套与平台无关、厂商无关的协议标准，使得开发人员能够方便的添加或更换底层APM的实现。
它是 CNCF 的项目。OpenTracing 协议的产品有 Jaeger、Zipkin 等等。
OpenTracing 数据模型
- Trace(s):
Trace(s) 在 OpenTracing 中是被 spans 隐式定义的。一个 trace 可以被认为是由一个或多个 span 组成的有向无环图。
比如，下图示例就表示一个 trace 由 8 个 span 组成，也就是一次链路追踪由 8 个 span 组成：
单个 trace(链路) 中 span 之间的关系 [Span A] ←←←(the root span) | +------+------+ | | [Span B] [Span C] ←←←(Span C is a `ChildOf` Span A) | | [Span D] +---+-------+ | | [Span E] [Span F] >>> [Span G] >>> [Span H] ↑ ↑ ↑ (Span G `FollowsFrom` Span F)
用时间轴来可视化这次链路追踪图，更容易理解：
Temporal relationships between Spans in a single Trace
––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–> time
[Span A···················································]
[Span B··············································]
[Span D··········································]
[Span C········································]
[Span E·······] [Span F··] [Span G··] [Span H··]
（来自：opentracing.io/specification/）
- Span:
1.3 OpenCensusSpan 是一次链路追踪里的基本组成元素，一个 Span 表示一个独立工作单元，比如一次 opentracing.io/specification/）
为什么又出现个 OpenCensus 这个项目？因为它有个好爹：google。要知道分布式跟踪的基础论文就是谷歌提出。
其实，刚开始它并不是要抢 OpenTracing 的饭碗，它只是为了把 Go 语言的 Metrics 采集、链路跟踪与 Go 语言自带的
profile 工具打通，统一用户的使用方式。但是随着项目发展，它也想把链路相关的统一一下。它不仅要做 Metrics 基础指标监控，
还要做 OpenTracing 的老本行：分布式跟踪。
1.4 OpenTracing 与 OpenCensus 对比2 者功能对比
1.5 OpenTelemetry这样出现 2 个标准也不是个事啊，如是就出现了 OpenTelemetry，它把 2 者合并在一起了。
OpenTelemetry 的核心工作目前主要集中在 3 个部分：
- 规范的制定和协议的统一，规范包含数据传输、API 的规范，协议的统一包含：HTTP W3C 的标准支持及GRPC等框架的协议标准
- 多语言 SDK 的实现和集成，用户可以使用 SDK 进行代码自动注入和手动埋点，同时对其他三方库（Log4j、LogBack等）进行集成支持；
- 数据收集系统的实现，当前是基于 OpenCensus Service 的收集系统，包括 Agent 和 Collector。
(1.4 1.5来自： github.com/open-telemetry/docs-cn)
OpenTelemetry 的最终形态就是实现 Metrics、Tracing、Logging 的融合。
OpenTelemetry 整体架构图：
（来自：opentelemetry.io/docs/）
Tracing API 中几个重要概念：
- TracerProvider：是 API 的入口点，提供了对 tracer 的访问。在代码里主要是创建一个 Tracer，一般是第三方分布式链路管理软件提供具体实现。默认是一个空的 TracerProvider("")，虽然也创建 Tracer，但是内部不会执行数据流传输逻辑。
- Tracer：负责创建 span，一个 tracer 表示一次完整的追踪链路。tracer 由一个或多个 span 组成。跟上面的 OpenTracing 数据模型很像，所以说是两者合并。
- Span：一次链路追踪操作里的基本操作元素。比如一次函数调用，一次 opentelemetry.io/docs/reference/specification/trace/api/
还有一个数据采样，www.cnblogs.com/jiujuan/p/16097314.html - 前面学习 dapper 论文的这篇文章有介绍。
小结：
一条链路追踪信息：
二、jaeger 简介有一条链路 trace，它是由一个或多个 span 组成， span 里会记录各种链路中的信息，跨进程的信息，各种 span 之间的关系。
使用哪种链路管理软件，则由 traceprovider 来设置。可以是 Jaeger，Pinpoint，Zipkin，Skywalking 等等。
span 中的信息收集到链路管理软件，然后可以用图来展示记录的链路信息和链路之间的关系。
Jaeger 是受到 Dapper 和 OpenZipkin 启发，是 Uber 开发的一款分布式链路追踪系统。
它用于监控微服务和排查微服务中出现的故障。
jaeger 架构图：
（来自：www.jaegertracing.io/docs/1.35/architecture/）
jaeger 安装：
三、kratos 中链路追踪使用参考我前面文章 ：www.cnblogs.com/jiujuan/p/13235748.html docker all-in-one 安装
前面介绍了那么多，应该对 opentelemetry 大致有了一个了解。下面就在 kratos 中使用 opentelemetry。
这里使用 jaeger 作为链路追踪的管理软件。
go 1.17
go-kratos 2.2.1
jaeger 1.35
下面代码来自 go-kratos 官方例子。
server 端在 main.go 中，有 grpc server 和 go-kratos.dev/docs/component/middleware/tracing/ 链路追踪
本文共计1891个文字，预计阅读时间需要8分钟。
分布式链路追踪简介
1. 分布式链路追踪介绍分布式链路追踪是一种用于监控分布式系统中服务间调用关系的技术。它能够帮助开发者了解请求在系统中的流转路径，从而快速定位和解决问题。
2. 分布式链路追踪概述关于分布式链路追踪的详细介绍，您可以查看我之前发布的文章。同时，我还分享了一篇关于微服务架构学习与思考的文章（09）：分布式链路追踪系统 - Dapper论文学习（https://www.cnb.com）。
一、分布式链路追踪发展简介 1.1 分布式链路追踪介绍关于分布式链路追踪的介绍，可以查看我前面的文章 微服务架构学习与思考(09)：分布式链路追踪系统-dapper论文学习(www.cnblogs.com/jiujuan/p/16097314.html) 。
这里的 OpenTelemetry 有一段发展历程。
APM(Application Performance Monitoring) 和 Distributed Tracing(分布式跟踪)，后者是前者的子集。
微服务架构流行起来后，为了监控和定位微服务中请求链路过长导致的定位和监控问题，分布链路监控也蓬勃发展起来。出现了
很多有名的产品，比如：Jaeger，Pinpoint，Zipkin，Skywalking 等等。这里有个问题，就是每家都有自己的一套数据采集标准和SDK。
为了统一这些标准，国外的人们就创建了 OpenTracing 和 OpenCensus 2 个标准。最先出现的是 OpenTracing。为了统一标准，后来两者合并为 OpenTelemetry。
1.2 OpenTracingOpenTracing 制定了一套与平台无关、厂商无关的协议标准，使得开发人员能够方便的添加或更换底层APM的实现。
它是 CNCF 的项目。OpenTracing 协议的产品有 Jaeger、Zipkin 等等。
OpenTracing 数据模型
- Trace(s):
Trace(s) 在 OpenTracing 中是被 spans 隐式定义的。一个 trace 可以被认为是由一个或多个 span 组成的有向无环图。
比如，下图示例就表示一个 trace 由 8 个 span 组成，也就是一次链路追踪由 8 个 span 组成：
单个 trace(链路) 中 span 之间的关系 [Span A] ←←←(the root span) | +------+------+ | | [Span B] [Span C] ←←←(Span C is a `ChildOf` Span A) | | [Span D] +---+-------+ | | [Span E] [Span F] >>> [Span G] >>> [Span H] ↑ ↑ ↑ (Span G `FollowsFrom` Span F)
用时间轴来可视化这次链路追踪图，更容易理解：
Temporal relationships between Spans in a single Trace
––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–> time
[Span A···················································]
[Span B··············································]
[Span D··········································]
[Span C········································]
[Span E·······] [Span F··] [Span G··] [Span H··]
（来自：opentracing.io/specification/）
- Span:
1.3 OpenCensusSpan 是一次链路追踪里的基本组成元素，一个 Span 表示一个独立工作单元，比如一次 opentracing.io/specification/）
为什么又出现个 OpenCensus 这个项目？因为它有个好爹：google。要知道分布式跟踪的基础论文就是谷歌提出。
其实，刚开始它并不是要抢 OpenTracing 的饭碗，它只是为了把 Go 语言的 Metrics 采集、链路跟踪与 Go 语言自带的
profile 工具打通，统一用户的使用方式。但是随着项目发展，它也想把链路相关的统一一下。它不仅要做 Metrics 基础指标监控，
还要做 OpenTracing 的老本行：分布式跟踪。
1.4 OpenTracing 与 OpenCensus 对比2 者功能对比
1.5 OpenTelemetry这样出现 2 个标准也不是个事啊，如是就出现了 OpenTelemetry，它把 2 者合并在一起了。
OpenTelemetry 的核心工作目前主要集中在 3 个部分：
- 规范的制定和协议的统一，规范包含数据传输、API 的规范，协议的统一包含：HTTP W3C 的标准支持及GRPC等框架的协议标准
- 多语言 SDK 的实现和集成，用户可以使用 SDK 进行代码自动注入和手动埋点，同时对其他三方库（Log4j、LogBack等）进行集成支持；
- 数据收集系统的实现，当前是基于 OpenCensus Service 的收集系统，包括 Agent 和 Collector。
(1.4 1.5来自： github.com/open-telemetry/docs-cn)
OpenTelemetry 的最终形态就是实现 Metrics、Tracing、Logging 的融合。
OpenTelemetry 整体架构图：
（来自：opentelemetry.io/docs/）
Tracing API 中几个重要概念：
- TracerProvider：是 API 的入口点，提供了对 tracer 的访问。在代码里主要是创建一个 Tracer，一般是第三方分布式链路管理软件提供具体实现。默认是一个空的 TracerProvider("")，虽然也创建 Tracer，但是内部不会执行数据流传输逻辑。
- Tracer：负责创建 span，一个 tracer 表示一次完整的追踪链路。tracer 由一个或多个 span 组成。跟上面的 OpenTracing 数据模型很像，所以说是两者合并。
- Span：一次链路追踪操作里的基本操作元素。比如一次函数调用，一次 opentelemetry.io/docs/reference/specification/trace/api/
还有一个数据采样，www.cnblogs.com/jiujuan/p/16097314.html - 前面学习 dapper 论文的这篇文章有介绍。
小结：
一条链路追踪信息：
二、jaeger 简介有一条链路 trace，它是由一个或多个 span 组成， span 里会记录各种链路中的信息，跨进程的信息，各种 span 之间的关系。
使用哪种链路管理软件，则由 traceprovider 来设置。可以是 Jaeger，Pinpoint，Zipkin，Skywalking 等等。
span 中的信息收集到链路管理软件，然后可以用图来展示记录的链路信息和链路之间的关系。
Jaeger 是受到 Dapper 和 OpenZipkin 启发，是 Uber 开发的一款分布式链路追踪系统。
它用于监控微服务和排查微服务中出现的故障。
jaeger 架构图：
（来自：www.jaegertracing.io/docs/1.35/architecture/）
jaeger 安装：
三、kratos 中链路追踪使用参考我前面文章 ：www.cnblogs.com/jiujuan/p/13235748.html docker all-in-one 安装
前面介绍了那么多，应该对 opentelemetry 大致有了一个了解。下面就在 kratos 中使用 opentelemetry。
这里使用 jaeger 作为链路追踪的管理软件。
go 1.17
go-kratos 2.2.1
jaeger 1.35
下面代码来自 go-kratos 官方例子。
server 端在 main.go 中，有 grpc server 和 go-kratos.dev/docs/component/middleware/tracing/ 链路追踪