什么是OpenTelemetry？日志、指标和跟踪的开源标准

OpenCensus、OpenTracing 和 OpenTelemetry。当您研究用于管理复杂多重云 IT 环境及其中运行服务的可观测能力解决方案时，这些只是您可能会遇到的一些开源技术。事实上，这些技术已经变得如此普遍，以至于任何可能不了解该主题全部范围的人都难于启齿。如果您碰巧属于这一类，请不要害怕，这篇文章会让您登堂入室！

在这些开源可观测能力工具中，有一个工具超然存在。让我们仔细研究一下，弄清楚这个工具及其涵盖的远程监测数据以及可以提供的利好。

什么是OpenTelemetry？

OpenTelemetry（也称为 OTel）是一个开源可观测能力框架，由一系列工具、API 和 SDK 组成，使 IT 团队能够检测、生成、收集和导出远程监测数据以进行分析和了解软件性能和行为。

要了解 OTel 所做的工作，了解可观测能力会有所帮助。粗略定义一下，可观测能力是一种根据系统生成外部数据（通常是日志、指标和跟踪）研判系统内部发生情况的能力。

OpenTelemetry致力于如何收集和发送可观测能力数据并使其具有通用格式。作为云原生计算基金会 (CNCF) 的孵化项目，OTel 旨在提供与供应商无关的统一库和 API 集——主要用于收集数据并将其传输到某个地方。自项目启动以来，包括Dynatrace在内的众多厂商,已加入这一阵营，同心协力让海量数据收集更简便、更易于使用。

要了解可观测能力和 OTel 的处理方法的重要性，让我们更深入地了解远程监测数据本身，以及它如何帮助组织转变其经营方式。

OpenTelemetry 参考架构。来源：OpenTelemetry 文档

什么是远程监测数据？

采集数据对于了解您的应用和基础架构在任何给定时间的表现至关重要。这些信息是从生态系统中的远程、通常无法访问的点收集的，并由某种工具或设备处理。监测从这里开始。由于容量限制，系统产生的数据极其丰富且难以长期存储——这是私有和公共云存储服务对 DevOps 团队的利好。

日志、指标和跟踪构成了所有远程监测数据的主要部分。

日志很重要，因为您肯定会希望系统对任何明显异常的事件进行记录。这些结构化、非结构化或纯文本形式的可读文件，可以告诉您涉及多重云环境中端点的任何事务的结果。然而，并非所有日志天生都是可审查的——这个问题导致了外部日志分析工具的出现。

指标是数字的数据点，表示为通常在一段时间内计算或聚合的计数或度量。指标有多个来源，包括基础设施、主机和第三方来源。虽然日志并不总是可访问的，但往往可以通过查询访问大多数指标。时间戳、值，甚至事件名称，都可以预先发现需要修复的日益严重的问题。

跟踪是一种从头到尾跟踪流程（例如，API 请求或其他系统活动）的行为，展示了服务之间的关联。密切关注该流程，对于了解您的生态系统如何运作、是否有效运作以及是否需要进行任何故障排除至关重要。跨度数据是跟踪的标志——其中包括诸如唯一标识符、操作名称、时间戳、日志、事件和索引等信息。

OpenTelemetry 如何工作？

OTel 是用于收集远程监测数据并将其导出到目标系统的专用协议。由于 CNCF 项目本身是开源的，最终目标是进一步提高数据收集的系统无关性。但是如何产生这些数据呢？

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

• 使用 API 检测您的代码，告诉系统组件要收集哪些指标以及如何收集它们

• 使用 SDK 缓存数据，并传输以进行处理和导出

• 分解数据、采样、过滤以减少噪音或错误，并使用多源背景信息来丰富数据

• 转换和导出数据

• 在基于时间的批处理中进行更多过滤，然后将数据向前移动到预先确定的后端

对于收集我们最关心的数据，提取过程至关重要。有两种主要方法可以解决这个问题：

• 本地提取。一旦数据安全地存储在本地缓存中，就会发生这种情况。这在本地或混合部署中很常见，其中时间序列数据和标签传输到云。云数据库擅长存储大量信息供以后参考，而这些数据通常具有商业价值或隐私限制。

• 跨度提取。我们也可以提取跨度格式跟踪数据。根据供应商的不同，这些数据可能会被直接或间接提取。跨度通常被索引，由根跨度和子跨度组成。该数据很有价值，因为它包含关键元数据、事件信息等。

这些方法对整个处理过程至关重要，因为如果不利用这些信息，流程就无法工作。

OpenTelemetry 的好处

收集应用数据并不是什么新鲜事。但是，从一个应用到另一个应用，收集机制和格式很少是一致的。这种不一致，对于只是试图了解应用健康状况的开发人员和 SRE 来说，可能是一场噩梦。

OTel 为向云原生应用添加可观测能力工具提供了事实上的标准。这意味着公司不需要花费宝贵的时间来开发收集关键应用数据的机制，而是可以花更多的时间来交付新功能。

这类似于 Kubernetes 如何成为容器编排的标准。它的广泛应用使组织更容易实施容器部署，因为他们不需要构建自己的企业级调度平台。使用Kubernetes进行模拟演示，很容易看到它为整个行业带来的好处。

OpenTracing 和 OpenCensus 发生了什么变化？

OpenTracing 在 2016 年成为 CNCF 项目，其目标是为分布式跟踪提供与供应商无关的规范，使开发人员能够通过检测他们的代码从头到尾跟踪请求。然后，谷歌在 2018 年将 OpenCensus 作为开源项目。这是基于谷歌的统计库，该库在内部用于从其分布式系统收集跟踪和指标。与 OpenTracing 项目一样，OpenCensus 的目标是为开发人员提供一个与供应商无关的库，用于收集跟踪和指标。

这导致了两个相互竞争的跟踪框架，也是人们口头说的“跟踪战争”。通常，竞争对最终用户来说是一件好事，因为它孕育了创新。然而，在开源规范世界中，竞争可能导致应用、贡献和支持不佳。

回到 Kubernetes 的例子，想象一下如果每个人都使用不同的调度解决方案，容器的采用会更加脱节和缓慢。为避免这种情况，在巴塞罗那举行的 KubeCon 2019 上宣布 OpenTracing 和 OpenCensus 项目将合并为一个名为 OpenTelemetry 的项目并加入 CNCF。

第一个 beta 版本于 2020 年 3 月发布，它仍然是继 Kubernetes 之后第二活跃的 CNCF 项目。

OpenTelemetry远程监测组件

OTel 由几个不同的组件组成，如下图所示。让我们从左到右从高层次看一下每一个组件：

OpenTelemetry 组件（来源：基于OpenTelemetry: 超越入门)

API

这些是核心组件并且与语言（例如 Java、Python、.Net 等）相关。API 为您的应用提供了基本的“开发途径”。

SDK

这也是一个与语言相关的组件，是提供 API 和导出器之间桥梁的中间人。SDK 允许进行额外的配置，例如请求过滤和事务采样。

过程导出器

这允许您配置要将其发送到哪个后端。导出器将检测部分与后端配置分离。这使得切换后端变得容易，而无需重新检测代码。

收集器

收集器接收、处理和导出远程监测数据。虽然在技术上不是必需的，但它是 OpenTelemetry 架构的一个非常有用的组件，因为它允许后端更灵活接收和发送应用的远程监测数据。

收集器有两种部署模型：

1. 与应用驻留在同一主机上的代理（例如，二进制、DaemonSet、sidecar 等）
2. 与应用完全分离的独立进程

由于收集器只是收集和发送远程监测的规范，因此它仍然需要一个后端来接收和存储数据。

OpenTelemetry 贡献者的现状

虽然 OTel 有几个较小的用户和个人贡献者，但大公司通过投入时间、审核、评论和提交确实推动了开发进程。在短短一个月内，该项目的总贡献超过 11,000 条。

Dynatrace、Splunk 和 Microsoft 都是前 10 名的贡献者。总体而言，有 100 多家公司和供应商定期或已经为 CNCF 的创意做出贡献。

它背后的社区既多样化又强大。GitHub、Slack 和 Twitter 等平台都有专门的社区或工作区。Stack Overflow 仍然是获取项目答案的好地方。那些寻求第一手数据的人甚至可以查阅CNCF DevStats仪表板获取更多信息。

OpenTelemetry 的未来计划是什么？

该项目于 2021 年 2 月发布 v1.0，目前仅支持跟踪和指标，日志仍处于初始规划阶段。除了确保从 OpenTracing 和 OpenCensus 顺利过渡之外，近期的计划是继续扩大覆盖范围。

Dynatrace 和 OpenTelemetry 一起可以为用户带来更多价值

作为OpenTelemetry 项目的主要贡献者， Dynatrace 致力于为技术团队提供无缝的可观测能力。 数据加背景信息是增强可观测能力的关键。Dynatrace 是唯一一个将高保真分布式跟踪、代码级可见性和跨云原生架构的高级诊断相结合的可观测能力解决方案。通过将 OTel 数据无缝集成到 PurePath—Dynatrace 的分布式追踪技术—Dynatrace OneAgent自动获取OTel数据，并提供OTel 范围之外的所有重要框架的工具。