深入探讨 OpenTelemetry：一种中立的遥测数据收集方式
对于任何开发人员来说，提高应用程序的可观察性都是一项重大挑战，这需要他们捕获应用程序产生的遥测数据。 按照剑桥词典的定义，遥测是指收集有关远程物体的信息，并通过电子方式将其传输到特定地点的科学或过程。
例如，用户在网站上的每一次点击或者会话都会产生大量的请求和跟踪数据，这些数据在网络、微服务、数据库等多个组件之间流动。
OpenTelemetry 是一个可观测性平台，它由一系列结构化的组件构成，这些组件可以组合使用，也可以单独使用。 此外，当今流行的框架和库的开发者现在拥有了一种标准方法，可以将遥测数据嵌入到这些库和框架中，从而为最终用户提供大量开箱即用的见解，帮助他们了解这些框架在幕后是如何运作的。
要理解 OpenTelemetry，首先需要理解什么是分布式追踪。
什么是分布式追踪？
随着我们的应用程序日益复杂，越来越多的服务参与到处理用户流量和完成交易的过程中，了解请求如何在我们的服务中传递，以及每个服务如何影响整体延迟变得至关重要。 这就是分布式追踪的作用。 它会捕获用户请求的延迟，以及请求路径中每个微服务返回响应所需的时间。
当用户发起请求时，我们需要创建一个追踪，它记录了我们的系统如何响应用户请求的所有信息。追踪由跨度组成，每个跨度代表了处理用户请求过程中涉及的特定请求和响应对。 父跨度描述了最终用户观察到的延迟。 子跨度用于了解分布式系统中特定服务是如何被调用并返回其延迟信息的。
什么是 OpenTelemetry？
OpenTelemetry 是由 CNCF 主持的一个开源项目，它提供了一种生成遥测数据的标准化方法。 它是通过合并 OpenTracing （用于生成追踪数据的标准）和 OpenCensus （用于生成指标数据的标准）而创建的。
OpenTelemetry 提供了一套 API、代理、收集器服务和库，用于从您的应用程序捕获分布式追踪和指标。 OpenTelemetry 标准化了我们收集遥测数据并将其发送到您选择的后端的方式。 这为您提供了一种与供应商无关的检测路径，并使您可以灵活地更改后端，而无需重新检测您的代码。
因此，您可以使用与供应商无关的代理来检测您的应用程序，同时仍然可以将您的指标和追踪发送给像 Datadog 这样的 SaaS 供应商。 如果您希望更换供应商（例如，从 Datadog 切换到 Dynatrace），您可以在不更改应用程序代码的情况下进行。
OpenTelemetry 项目旨在提供一组 API 库和代理，用于从您的应用程序捕获指标和分布式追踪。 它支持多种编程语言和平台。 OpenTelemetry 项目还包括一个可选的收集器服务，以及一个专门的规范存储库。 需要明确的是，OpenTelemetry 本身不是像 Jaeger 或 Prometheus 那样的可观测性后端，而是帮助将数据导出到开源和商业后端的工具。
以下是 OpenTelemetry 提供的关键功能：
- 标准化遥测数据的收集方式，方便组织在不同供应商之间迁移。
- 采用与供应商无关的开放标准语义约定，确保数据收集过程的一致性。
- 支持多种部署方式，如代理、网关或多种不同的收集器。
- 支持多种上下文传播格式，便于迁移。
- 提供端到端的解决方案，用于生成、发出、收集、处理和导出遥测数据。
- 允许并行地将数据发送到多个目标，并对数据流进行完全控制。
OpenTelemetry 的核心组件
OpenTelemetry 的核心组件包括：
- Proto：此组件用于为收集器、检测库等定义 OpenTelemetry 的语言无关的接口类型。
- 收集器：收集器用于接收、处理和导出遥测数据。 此收集器的实现必须与供应商无关。 默认情况下，所有遥测数据都由该位置的检测库导出。
- 规范（Specification）：此组件描述了 API、SDK 和数据在不同语言中的实现要求和预期。 API 用于生成遥测数据，SDK 提供 API 的处理和导出功能。 数据具有语义约定，无需更改任何代码即可支持不同的供应商。
- 检测库：这些库作为 OpenTelemetry 项目的一部分，以多种语言提供。 它们用于为其他库提供可观测性，通过调用 OpenTelemetry API 来观察所有应用程序。
OpenTelemetry 架构
图片来自 New Relic
从高层次来看，OpenTelemetry 由三个主要部分组成：
- 用于检测应用程序、库和框架的一组 API。
- 实现 API 的 SDK。
- 可选的收集器，可以在您需要的任何地方摄取、聚合和导出遥测数据。
API 的目的是为库和应用程序代码创建检测。 API 主要包含四个部分：追踪、计量、共享上下文和语义约定。
- 追踪器（Tracer） API 支持创建、注释和完成跨度。
- 仪表（Meter） API 由多个度量工具组成，例如观察器、值记录器和计数器。
- 您可以通过启用上下文 API 来追踪和执行跨度上下文，并在系统内外传播该上下文。
- 语义约定定义了所有指南和规则，例如命名跨度、属性、标签和度量工具。 实现这些约定是为了确保不同语言的实现和外部检测的一致性。
在共享上下文中，上下文实现在追踪器和仪表之间，使得所有非观察者度量记录都能够在执行跨度的上下文中发生。 允许 SDK 捕获指标值的示例范围。 您可以使用传播器自定义上下文，这可以将跨度上下文传播到系统中和从系统中传播出去，从而实现真正的分布式追踪。
收集器是 OpenTelemetry 架构的重要组成部分。 它是一个独立的服务，可以接收、处理和导出来自各种来源的遥测数据，包括 OpenCensus、Zipkin、Jaeger 和 OpenTelemetry 协议。 使用收集器，您可以将跨度和指标导出到多个供应商和开源遥测系统。
OpenTelemetry 架构提供了一个开箱即用的完整遥测解决方案。 您还可以根据需要使用多个扩展点进行自定义。
OpenTelemetry 的工作原理
在部署中的每个服务内部，都需要安装 OpenTelemetry 客户端。 该客户端就是 SDK； 反过来，SDK 提供一个 API。 应用程序框架和库使用此检测 API 来描述它们正在执行的工作。 然后，SDK 将收集到的观察结果导出到名为 Collector 的数据流水线服务。
OpenTelemetry 使用自己的数据协议 OTLP，但收集器可以将 OTLP 转换为多种格式，包括 Zipkin、Jaeger 和 Prometheus。 值得注意的是，OpenTelemetry 本身不提供后端或分析工具。 它的核心目标是标准化云环境中计算机的操作方式，而不是标准化我们分析数据的方式。 相反，我们希望 OpenTelemetry 能够帮助新的分析工具快速启动，而无需重建整个遥测软件生态系统，从而推动可观测性的发展。
当您在系统中发送大量数据时，有很多因素需要考虑。 幸运的是，OpenTelemetry 已经考虑到了所有这些因素，并为每个问题提供了解决方案。 例如，OpenTelemetry 非常灵活，它可以处理多种上下文传播格式，这意味着即使存在标准，也仍有选择的余地。 因此，如果您使用 w3c 追踪上下文格式或 b3 传播等机制，这些标准允许您的服务连接。
总结
OpenTelemetry 收集各种观察结果，其中分布式追踪指标和系统资源是最重要的。 OpenTelemetry 不会将它们视为单独的信号，而是将它们编织在一起，并提供索引和上下文，使您可以在后端聚合和交叉索引所有这些信号。
除了数据收集之外，OpenTelemetry 还提供数据处理和流水线功能，允许您更改数据格式、操作数据，以及在现代系统中构建强大的遥测流水线所需的所有工具。
以上就是关于 OpenTelemetry 的所有内容，快去尝试使用这个工具吧！