·2023-03-27 09:31

系统架构师·None

基于OpenTelemetry进行全链路追踪

字数 5018阅读 1258评论 0赞 1

内容摘要：

OpenTelemetry是云原生计算基金会沙盒项目，提供统一的供应商不可知库/API、SDK和其他工具，帮助IT团队检测应用程序并生成、收集和导出遥测数据，以分析和了解软件架构性能和系统行为。它具有语言中立的规范和可扩展架构，提供高水平可观察性的方法，包括收集器代码、Contrib接收器、处理器和导出器、Kubernetes操作员、Go和PythonAPI和SDK等。

当前摘要为AI生成

Hello folks，我是 Luga，今天我们来分享一下与云原生体系有关的话题- 云原生可观测性- OpenTelemetry 。 作为一个云原生“核心”标准， OpenTelemetry 在观测分布式微服务应用程序和云基础设施的可见性和控制自动化层面具有举足轻重的意义。

— **0 **1  —

## **Observability-可观测性鸟瞰**

正如之前文章所述，可观测性是根据对系统产生的外部数据（例如日志、指标和跟踪）的了解来获取系统内部发生的事情的能力。

可观测性通常通过遥测数据来辅助，遥测数据可以通过 Dynatrace 以及 OpenTelemetry 等开源项目提供。OpenTelemetry 是一个云原生计算基金会 (CNCF)沙盒项目，其目标是提供一组统一的供应商不可知库/API、SDK 和其他工具。它的主要贡献者之一是 Dynatrace。

基于 OpenTelemetry，IT 团队可以检测他们的应用程序并生成、收集和导出遥测数据，以分析和了解软件架构性能和系统行为。

正如 Kubernetes 已成为容器编排的事实标准一样，OpenTelemetry 现在是为云原生应用程序添加可观测性的事实标准。这意味着公司无需花费宝贵的时间开发用于收集应用程序遥测数据的机制，而是可以专注于他们的主要产品。

![](/home/attachment/202303/27/162937_167987979383370.png)

— **0 **2  —

## **什么是 OpenTelemetry？**

OpenTelemetry（也称为 OTel）是一个开源可观察性框架，由一系列工具、API 和 SDK 组成。Otel 使 IT 团队能够检测、生成、收集和导出遥测数据以进行分析并了解软件性能和行为。 作为一个CNCF项目， OpenTelemetry 定义了语言中立的规范，并提供了API、SDK的集合，用于以与供应商无关的方式处理日志、度量和跟踪等可观察性数据。该项目由两个竞争项目——OpenTracing 和 OpenCensus 的融合而成，并得到了来自谷歌、微软、亚马逊的主要云提供商以及可观察性领域几乎所有供应商的支持——Splunk、Elastic、Datadog、LightStep、DynaTrace、NewRelic、Logzio、HoneyComb 等。让我们探索在现有和未来的绿地项目中采用 OpenTelemetry 的好处。

![](/home/attachment/202303/27/162937_167987982133039.png)

1、OpenTelemetry 规范的语言中立性允许以不同语言实现

目前，截至本文撰写时，OpenTelemetry 的 SIG- 特殊兴趣组提供了一些最广泛使用的通用语言的实现：C++，。Net，Java，Javascript，Python，Go，Rust，Erlang，Ruby，PHP，Swift。这些是一组专门的贡献者，专注于单一语言的实现。如果有一个软件项目使用目前不受支持的语言，那么将来可能会得到支持。所有这些都意味着在实现软件组件时具有更大的灵活性；无论语言选择如何，仪器都是一样的。

2、OpenTelemetry可扩展性架构

OpenTelemetry 的可扩展架构 意味着库/插件作者可以使用 API 仪器化他们的代码，当这些工件在实现 OpenTelemetry SDK 的服务或应用程序中使用时，服务代码和第三方库的性能都有可见性。微软的分布式应用程序运行时库就是一个例子。有Spring、Express 等流行框架的插件。

3、OpenTelemetry 防止供应商锁定

OpenTelemetry Collector 允许接收、处理和导出遥测数据，支持不同的开源有-Jaeger、Prometheus、Fluent Bit、W3C TraceContext 格式、Zipkin 的 B3 标头等。更重要的是，随着出口商对不同遥测后端的实施，供应商之间的切换变得轻而易举。例如，人们可以将他们的跟踪数据传输到 NewRelic、Elastic、Zipkin 的部署实例等......这都是收集器上的简单配置更改。将其视为仪器作为一种抽象形式，其中遥测数据的目标后端从应用程序/服务中抽象出来。

— **0 **3  —

**OpenTelemetry 参考架构**

OpenTelemetry 架构围绕几个关键组件展开，其中一些组件可以灵活实现。主要组成部分包括：

1、API 和 SDK

OpenTelemetry SDK 是开发人员用来使用指标、跟踪和日志检测其应用程序的库。而 OpenTelemetry API 定义了应用程序如何相互通信并用于检测应用程序或服务。它们通常可供开发人员在流行的编程语言（例如，Ruby、Java、Python）中使用。因为它们是 OpenTelemetry 标准的一部分，所以它们可以与任何 OpenTelemetry 兼容的后端系统一起使用，从而无需在未来重新检测。

SDK 也是特定于语言的，提供 API 和导出器之间的桥梁。它可以对跟踪和聚合指标进行采样。

2、采集器

OpenTelemetry Collector 是一个可选的中间代理，基于其，可以运行它来接收、处理和导出遥测数据。应用程序通过 OTLP 将遥测数据发送到 OTel 收集器，OTel 收集器在导出到各种可观察性供应商之前执行中间处理，例如批处理或速率限制。

需要注意的是：虽然拥有这个中间代理可能会有所帮助，但它确实会为您的堆栈增加一层额外的基础设施和复杂性。

Collector 的工作基本上围绕处理、过滤、聚合和批量遥测进行，为开发人员提供更大的灵活性来接收、整形和发送数据到多个后端。目前适用于如下两种主要部署模型：

* 作为应用程序内或与应用程序位于同一主机中的代理，充当主机的数据源（默认情况下，OpenTelemetry 假定本地收集器可用）
  * 作为接收、导出和处理遥测数据的数据管道网关

Collector 由三个组件组成：接收器、处理器和导出器，具体可参考如下所示：

接收器

例如，Jaeger、Prometheus 等，负责通过侦听收集器上特定端口上的调用来推送或拉取应用程序的信号。它们适用于 gRPC 和 HTTP 协议。可以在 GitHub 上找到特定场景或框架的完整接收器列表。

处理器

处理器位于接收器和输出器之间；它们使我们能够在数据通过导出器到达后端之前通过过滤、格式化和丰富数据来塑造数据。常见用例包括数据清理以删除敏感或私人信息、从跨度中导出指标或决定将哪些信号保存到后端。

通常，有许多可用的受支持处理器供使用，当然，也可以开发自己的处理器。它们按顺序工作，因此配置顺序很重要。尽管处理器不是必需的，但可能会根据数据源推荐一些处理器。

导出器

导出器可以将数据推送或拉取到一个或多个配置的后端或目的地（例如，Kafka、OTLP）。其工作方式根据需要将数据转换为不同的格式并将其发送到定义的端点。导出器在检测和后端配置之间创建了一个分离层，因此用户可以在不重新检测代码的情况下切换后端。它支持 HTTP 或 gRPC 协议。流行的导出器包括 Jaeger、Prometheus 和 Zipkin，以及大量其他选项。

3、 开放遥测协议

OpenTelemetry 协议 (OTLP) 是 OpenTelemetry 成功的原因之一。它是一种不可知论协议规范，定义了数据编码和用于发送跟踪、指标和日志的传输协议。它可以将数据从 SDK 发送到收集器，然后从收集器发送到选定的后端。使用 Collector 元素，我们可以通过配置适当的接收器从第三方框架中抽象出来。

目前，OTLP 使用协议缓冲区架构 (protobuf)，并支持 gRPC 和 HTTP1.1（JSON over HTTP）传输。

![](/home/attachment/202303/27/162937_167987989962072.png)

— **0 **4  —

**OpenTelemetry 如何工作？**

OTel 是一种专门用于收集遥测数据并将其导出到目标系统的协议。由于 CNCF 项目本身是开源的，最终目标是使数据收集比目前更加系统不可知。但是这些数据是如何生成的呢？

数据生命周期从开始到结束有多个步骤。以下是解决方案所采取的步骤，以及它在此过程中生成的数据：

1、使用 API 检测我们所构建的代码，告诉系统组件要收集哪些指标以及如何收集它们

2、使用 SDK 汇集数据，并将其传输以进行处理和导出

3、分解数据、对其进行采样、过滤以减少噪音或错误，并使用多源上下文化对其进行丰富

4、转换和导出数据

5、在基于时间的批次中进行更多过滤，然后将数据向前移动到预定的后端

![](/home/attachment/202303/27/162937_167987993072228.png)

如上所述，OpenTelemetry 是一个 CNCF 项目。 基于市场活跃度以及社区的推动与发展综合评估 ，目前，OpenTelemetr y项目已是第二活跃的 CNCF 项目，仅次于 Kubernetes。

关于 OpenTelemetry 的资料库，详情可参考如下：

1、OpenTelemetry 的主要组件

open-telemetry/opentelemetry-specification - OTel 规范（协议、度量、跟踪、日志、行李和根 OTel 的许多其他规范）、模式和语义约定

open-telemetry/oteps - 项目的增强建议

open-telemetry/opentelemetry-proto - OTLP 的 Protobuf 定义

2、OTel 收集器存储库

open-telemetry/opentelemetry-collector - 核心收集器代码，包括用于自定义收集器发行版构建的ocb工具

open-telemetry/opentelemetry-collector-contrib - 收集器的 Contrib 接收器、扩展、处理器和导出器

open-telemetry/opentelemetry-collector-releases - 核心和 contrib 发行版的发行版不在上述两个 repos 中，但它们在这里包括发行发行版的清单和 Dockerfile

open-telemetry/opentelemetry-operator - 用于处理收集器的 Kubernetes 操作员，包括用于观察到的应用程序 pod 的收集器边车注入

3、OTel 特定于语言的工具

open-telemetry/opentelemetry-go - Go API 和 SDK

open-telemetry/opentelemetry-go-contrib - OTel Go 的扩展，包括仪器和传播器

open-telemetry/opentelemetry-python - Python API 和 SDK

open-telemetry/opentelemetry-python-contrib - OTel Python 的扩展

OpenTelemetry 是一个伟大的项目，它提供了一种在我们开发的软件中实现高水平可观察性的方法。通过使用 OTel，我们无需更改任何代码即可获得最大的洞察力并回答未来的问题。我强烈建议大家可以深入了解 OpenTelemetry 的精彩世界！如果你愿意，精彩一直会继续！

更多关于 OpenTelemetry 的技术文章，将在后续文章中讲述，欢迎关注，谢谢！

Adiós !

云原生可观测性云原生容器云微服务

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

基于OpenTelemetry进行全链路追踪

添加新评论0 条评论

文章目录展开目录

作者其他文章

相关文章

相关问题

相关资料