毕设&课设&项目&实训-基于 OpenTelemetry 的链路追踪实践（阿里云平台）.zip

# 阿里云 OpenTelemetry 实践 > 本文部分内容参考 https://opentelemetry.io/ ## 基本概念 ### 分布式链路追踪 **分布式链路追踪（Distributed Traces）**，更常见的说法是**链路追踪（Trace）**，用于记录由应用程序或最终用户提出的请求在多服务架构（如微服务或 serverless 应用程序）中所传播的路径。 如果没有链路追踪，要想找出分布式系统中性能问题的原因是很困难的。 链路追踪提高了我们的应用或系统健康状况的可见性，让我们能够调试难以在本地重现的行为。链路追踪对于分布式系统来说是必不可少的，因为这些系统通常有非确定性的问题，或者过于复杂而无法在本地重现。 链路追踪使调试和理解分布式系统变得不那么困难，因为它分解了一个请求在分布式系统中流动时发生的情况。 一个链路追踪是由一个或多个 **Span** 组成的。第一个 Span 代表根 Span。每个根 Span 代表一个请求从开始到结束。父级 Span 下面的 Span 提供了一个更深入的背景，即在一个请求中发生了什么（或者说哪些步骤构成了一个请求）。 许多提供链路观测的后端将一个 Traces 可视化为瀑布图，看起来可能是这样的。  瀑布图显示了根 Span 和其子 Span 之间的父子关系。当一个 Span 封装了另一个 Span，这也代表了一种嵌套关系。 ### Span 一个 Span 代表一个工作单位或操作单位。它跟踪一个请求所做的具体操作，描绘出在执行该操作的时间内所发生的事情。 Span 包含名称、与时间相关的数据、结构化的日志信息和其他元数据（如属性，Attributes），以提供关于它所追踪的操作的信息。 下面是一个 Span 中的信息类型的例子。 | Key | Value | | :--------------: | :-------------------------------------------------------------------------------------------------------------------: | | net.transport | IP.TCP | | net.peer.ip | 10.244.0.1 | | net.peer.port | 10243 | | net.host.name | localhost | | http.method | GET | | http.target | /cart | | http.server_name | frontend | | http.route | /cart | | http.scheme | http | | http.host | localhost | | http.flavor | 1.1 | | http.status_code | 200 | | http.user_agent | Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36 | ## 背景 ### 链路追踪为什么重要 微服务架构使开发者能够更快、更独立地构建和发布软件，因为他们不再受制于与单体架构相关的复杂的发布流程。 随着这些分布式系统的扩展，开发人员越来越难看到自己的服务是如何依赖或影响其他服务的，特别是在部署后或停运期间，速度和准确性至关重要。 并且，链路追踪带来的可观察性使开发者和运营商二者都能进一步明确系统的状态。 ### 链路追踪的各种实践 为了使一个系统可以被观察到，它必须被**插桩（instrumented）**。也就是说，代码必须发出跟踪、度量和日志，这些数据也被称为**遥测数据**。然后，这些数据必须被发送到**观测者（Observability）** 后端。现在有很多观测者后端，从一些开源工具（如 Jaeger 和 Zipkin）到商业 SaaS 产品。 过去，对代码进行检测的方式会有所不同，因为每个观测者后端都有自己的检测库和代理，用于向工具发送数据。 这意味着向观测者后端发送数据时没有标准化的数据格式。此外，如果一个公司选择更换观测者后端，就意味着他们必须重新对其代码进行测量，并配置新的代理，以便能够向所选择的新工具发射遥测数据。 由于缺乏标准化，最终的结果是缺乏数据的可移植性，并给用户带来了维护插桩库的负担。 认识到标准化的需要，云计算社区走到一起，两个开源项目诞生了。OpenTracing（云原生计算基金会（CNCF）项目）和 OpenCensus（谷歌开源社区项目）。 - **OpenTracing** 提供了一个供应商中立的 API，用于将遥测数据发送到观测者后端；不过，它依赖于开发者实现自己的库来满足规范。 - **OpenCensus** 提供了一套特定语言的库，开发者可以用它来检测他们的代码，并将其发送到他们支持的任何一个后端。 ### OpenTelemetry 的诞生 为了拥有一个单一的标准，OpenCensus 和 OpenTracing 在 2019 年 5 月被合并为 OpenTelemetry（简称 OTel）。作为一个 CNCF 的孵化项目，OpenTelemetry 吸取了两个项目的精华，并去其糟粕。 OTel 的目标是提供一套标准化的、厂商无关的 SDK、API 和工具，用于提取、转换和发送数据到观测者后端。 ### OpenTelemetry 能做什么 - 每种编程语言都有一个单一的、与供应商无关的插桩库，支持自动和手动插桩。 - 提供一个单一的供应商中立的采集器二进制文件，可以以各种方式部署。 - 一个端到端的实现，以生成、发送、收集、处理和导出遥测数据。 - 完全控制你的数据，能够通过配置将数据并行地发送到多个目的地。 - 开放标准的语义约定，以确保供应商的数据收集不受影响 - 能够平行地支持多种上下文传播格式，以确保随着标准的发展，程序代码能够顺利迁移。 - 无论你在链路中处于什么位置，都能保证你的下游链路对你可见。 由于支持各种开源和商业协议、格式和上下文传播机制，以及为 OpenTracing 和 OpenCensus 项目提供兼容，在项目中采用 OpenTelemetry 是很容易的。 不过，与 Jaeger 、 Zipkin 等不同。OpenTelemetry 并不提供观测后端，它更类似于一种统一的 API ，用于给不同的观测后端提供数据。 ## 实践 ### 目的 以阿里云作为观测者（Observability）后端，OpenTelemetry 为遥测接口。实现一个如下图所示的链路追踪： <center> _拓扑图_  _节点列表_  | Node Name | Language | Instrumentation | | :---------: | :------: | :----------------: | | otlp-server | Golang | Manual | | otlp-client | Golang |