什么是OpenTelemetry，以及它如何为您的应用程序提供可操作的洞察力

让我们讨论OpenTelemetry – 一种供应商中立的标准方法来收集遥测数据。

为应用程序提供更好的可观察性对于任何开发人员来说都是一个巨大的挑战，因为他们需要捕获应用程序的遥测数据。剑桥词典定义遥测为收集关于远离的物体的信息并将信息以电子方式发送到某个地方的科学或过程。

例如，用户在网站上的单击或会话会产生许多请求和跟踪流动在网络，微服务，数据库等之间。

OpenTelemetry是一个可观察性平台，它是一组良好分解的组件，可以一起使用或按需使用。此外，我们今天使用的框架和库的开发人员现在有了一种标准的方式将遥测数据集成到这些库和框架中，为最终用户提供了许多开箱即用的洞察力，了解这些框架在内部执行的情况。

要了解OpenTelemetry，首先需要了解分布式跟踪是什么。

什么是分布式跟踪？

随着我们的应用程序变得越来越复杂，并且越来越多的服务参与到为用户提供流量和完成事务的过程中，了解请求如何穿越我们的服务以及每个服务对总体延迟的贡献变得越来越重要。这就是分布式跟踪所做的。它捕获用户请求的路径和每个微服务返回响应所需的时间。

当用户发出请求时，我们希望创建一个跟踪，即完全描述我们的系统如何响应用户请求的信息。跟踪由span组成，每个span表示与为用户请求提供服务的特定请求和响应对。父span描述了最终用户观察到的延迟。子span用于了解在分布式系统中调用并响应其延迟信息的特定服务。

什么是OpenTelemetry？

OpenTelemetry是一个由CNCF托管的开源项目，提供了一种生成遥测数据的标准方法。它由生成跟踪数据的标准-OpenTracing和生成指标数据的标准-OpenMetrics的合并创建。

OpenTelemetry提供了一套API、代理、collector services和库，用于捕获应用程序的分布式跟踪和指标。OpenTelemetry标准化了我们如何收集遥测数据并将其发送到您选择的后端。这为您提供了一种供应商中立的仪器化路径，并使您能够在不再仪器化代码的情况下更改后端。

因此，您可以使用供应商中立的代理来为应用程序进行仪器化，同时将指标和跟踪发送到像Datadog这样的SaaS供应商。然后，如果您想要切换供应商（例如，从Datadog切换到Dynatrace），您可以在不更改应用程序代码的情况下进行操作。

OpenTelemetry项目旨在为您的应用程序提供一套API、库和代理，以捕获来自应用程序的指标和分布式跟踪。这适用于许多语言和平台。OpenTelemetry项目还包括一个可选的收集器服务，并有一个专用的规范存储库。要明确的是，OpenTelemetry不是Jaeger或Prometheus，它们是可观察的后端。但它有助于将数据导出到开源和商业后端。

以下是OpenTelemetry提供的功能：

标准化收集遥测数据的过程，以便组织可以遵循，轻松在供应商之间切换
供应商无关的、开放标准的语义约定，用于数据收集过程
可以部署为代理或网关等多种方式的收集器
支持多种上下文传递格式以进行迁移
端到端解决方案，用于生成、发出、收集、处理和导出遥测数据
可并行发送数据到各种目标，并对其进行完全控制的功能

OpenTelemetry组件

以下是OpenTelemetry的核心组件:

Proto: 此组件用于定义用于OpenTelemetry的收集器、仪器库等无语言依赖的接口类型。
Collector: 收集器用于接收、处理和导出遥测数据。此收集器的实现必须与供应商无关。默认情况下，所有仪器库导出的遥测数据都在此位置。
Specification: 此组件描述了不同语言实现的要求和期望，包括API、SDK和数据。API为实现SDK提供的API生成遥测数据、处理和导出能力。数据具有支持各种供应商的语义约定，而无需更改任何代码。
仪器库: 这些库是OpenTelemetry项目的一部分，提供多种语言支持。使用这些库可以为其他库提供可观察性，通过调用OpenTelemetry API使所有应用程序被观察到。

OpenTelemetry架构

在高层次上，OpenTelemetry由三个主要组件组成：

一组用于为应用程序、库和框架进行仪器化的API。
SDK实现了这些API。
一个可选的收集器可以在需要的任何位置接收、聚合和导出遥测数据。

API的目的是为库和应用程序代码创建仪器化。API有四个主要部分：追踪、计量器、共享上下文和语义约定。

追踪API支持创建、注释和完成跨度。
计量器API由多个度量仪器组成。这些仪器的示例包括观察者、值记录器、计数器。
通过启用上下文API，您可以跟踪和执行跨度上下文，并在系统内部和外部传播该上下文。
语义约定中包含了命名的所有准则和规则，例如跨度、属性、标签和度量仪器的命名。这些约定的实施旨在确保不同语言实现和外部仪器化之间的一致性。

在共享上下文中，上下文实现位于跟踪器和计量器之间，并允许在执行跨度的上下文中进行所有非观察者度量记录。这种功能允许SDK捕获度量值的示例跨度。您可以使用传播器自定义上下文，以使跨度上下文在系统内部和外部传播，实现真正的分布式跟踪。

收集器是OpenTelemetry架构的一个重要部分。它是一个独立的服务，可以从包括OpenCensus、Zipkin、Jaeger和OpenTelemetry协议在内的各种来源接收、处理和导出遥测数据。使用收集器，您可以将跨度和度量导出到多个供应商和开源遥测系统。

OpenTelemetry架构提供了一个开箱即用的完整遥测解决方案。您还可以根据需要使用多个扩展点进行自定义。

OpenTelemetry如何工作？

在部署的每个服务内，安装OpenTelemetry客户端。客户端是SDK；SDK反过来具有API。您的applications frameworks和库使用此工具API来描述它们正在进行的工作。然后，SDK将收集到的观测数据导出到称为Collector的数据管道服务中。

OpenTelemetry具有自己的数据协议OTLP，但Collector可以将OTLP转换为包括Zipkin、Jaeger和Prometheus在内的各种格式。值得注意的是，OpenTelemetry不提供自己的后端或分析工具；这是因为它是OpenTelemetry核心的标准化努力。目标是提供一种通用语言，用于描述云环境中计算机的操作。目标不是标准化我们如何分析这些数据。相反，我们希望OpenTelemetry能够通过允许新的分析工具快速启动而无需重建整个遥测软件生态系统来推动可观测性世界向前发展。

当您在系统中发送大量数据时，有很多要考虑的事情。幸运的是，OpenTelemetry已经考虑到了所有这些问题，并针对每个问题提供了解决方案。首先，OpenTelemetry具有灵活性，可以处理多种上下文传播格式。这意味着即使存在一个标准，仍然可以在该标准内进行选择。因此，如果您使用的是类似于w3c跟踪上下文格式或b3传播的东西，这些是标准内的不同标准，允许您的服务连接这些点。