什么是 OpenTelemetry？日志、指标、跟踪的开源标准
什么是 OpenTelemetry？开源可观测性技术的范围可能令人望而生畏，而且很容易不知所措。然而，在管理复杂的多云环境及其上运行的服务时，标准化非常重要，这就是 OpenTelemetry 的用武之地。OpenTelemetry 诞生于 OpenCensus 和 OpenTracing 的组合，并已成为开源遥测标准。
在本博客中，我们将仔细研究 OpenTelemetry，以消除有关它是什么、它涵盖的遥测数据以及它可以提供的好处的任何困惑。
OpenTelemetry 是什么？
OpenTelemetry（也称为 OTel）是一个开源可观测性框架，由工具、API 和 SDK 的集合组成。 OTel 使 IT 团队能够检测、生成、收集和导出遥测数据以进行分析并了解软件性能和行为。
要理解 OTel 所做的事情，有助于理解可观察性。宽松地定义，可观察性是根据系统产生的外部数据（通常是日志、指标和跟踪）的知识来了解系统内部发生的情况的能力。
OpenTelemetry发挥作用的地方在于拥有可观测数据收集和发送方式的标准格式。作为云原生计算基金会 (CNCF) 孵化项目，OTel 旨在提供统一的供应商无关库和 API 集，主要用于收集数据并将其传输到某个地方。自该项目启动以来，许多供应商都加入进来，帮助使丰富的数据收集变得更容易、更易于使用。
为了理解为什么可观测性和 OTel 的方法如此重要，让我们更深入地了解遥测数据本身以及它如何帮助组织转变其业务方式。
上图来自 OpenTelemetry 文档
什么是遥测数据？
捕获数据对于了解应用程序和基础设施在任何给定时间的执行情况至关重要。这些信息是从生态系统中通常无法访问的远程点收集的，并通过某些工具或设备进行处理。监控从这里开始。由于容量限制，数据非常丰富且难以长期存储。因此，私有云和公共云存储服务为 DevOps 团队带来了福音。
日志、指标和跟踪构成了所有遥测数据的大部分。
日志很重要，因为您自然会希望对整个系统中的显著异常进行基于事件的记录。这些可读文件可以是结构化、非结构化或纯文本形式，可以告诉您涉及多云环境中端点的任何事务的结果。然而，并非所有日志本质上都是可审查的——这个问题引发了外部日志分析工具的出现。
指标是表示为计数或度量的数值数据点，通常随着时间的推移计算或聚合。指标源自多个来源，包括基础设施、主机和第三方来源。虽然日志并不总是可访问，但大多数指标都可以通过查询访问。时间戳、值甚至事件名称都可以预先发现需要修复的日益严重的问题。
跟踪是从开始到结束跟踪流程（例如 API 请求或其他系统活动）而产生的，显示服务如何连接。密切关注这条路径对于了解您的生态系统如何运作、是否有效运作以及是否需要进行故障排除至关重要。跨度数据是跟踪的标志，包括唯一标识符、操作名称、时间戳、日志、事件和索引。
OpenTelemetry 如何工作？
OTel 是一种专门的协议，用于收集遥测数据并将其导出到目标系统。由于 CNCF 项目本身是开源的，因此最终目标是使数据收集比目前更加与系统无关。但这些数据是如何生成的呢？
数据生命周期从开始到结束有多个步骤。以下是该解决方案采取的步骤以及在此过程中生成的数据：
- 使用 API 检测您的代码，告诉系统组件要收集哪些指标以及如何收集它们
- 使用 SDK 汇集数据并传输数据以进行处理和导出
- 分解数据、对其进行采样、过滤以减少噪声或错误，并使用多源上下文丰富数据
- 转换并导出数据
- 基于时间的批次进行更多过滤，然后将数据移至预定后端
摄取对于收集我们最关心的数据至关重要。有两种主要方法可以解决这个问题：
- 局部摄入。一旦数据安全地存储在本地缓存中，就会发生这种情况。这在本地或混合部署中很常见，其中时间序列数据和标签传输到云。云数据库擅长存储大量信息以供以后参考，而这些数据通常具有商业价值或隐私限制。
- 跨度摄入。我们还可以获取跨度格式的跟踪数据。根据供应商的不同，这些数据可能会被直接或间接获取。 Span 通常是有索引的，并且由根 Span 和子 Span 组成。这些数据很有价值，因为它包含重要的元数据、事件信息等。
这些方法对于整个流程至关重要，因为如果不利用这些信息，流程就无法运行。
OpenTelemetry 的优点
收集应用程序数据并不是什么新鲜事。然而，一个应用程序与另一个应用程序的收集机制和格式很少是一致的。对于那些只是想了解应用程序运行状况的开发人员和 SRE 来说，这种不一致可能是一场噩梦。
OTel 提供了向云原生应用程序添加可观察仪器的事实上的标准。这意味着公司可以花更少的时间开发收集关键应用程序数据的机制，而可以花更多的时间提供新功能。
这类似于 Kubernetes 如何成为容器编排的标准。这种广泛的采用使组织更容易实施容器部署，因为他们不需要构建自己的企业级编排平台。使用Kubernetes作为其未来的模拟，很容易看出它可以为整个行业带来的好处。
OpenTracing 和 OpenCensus 发生了什么？
OpenTracing于 2016 年成为 CNCF 项目，目标是为分布式跟踪提供与供应商无关的规范，使开发人员能够通过检测其代码来从头到尾跟踪请求。然后，Google 在 2018 年将 OpenCensus 项目开源。该项目基于 Google 的 Census 库，该库在内部用于从其分布式系统收集跟踪和指标。与 OpenTracing 项目一样， OpenCensus旨在为开发人员提供一个与供应商无关的库来收集跟踪和指标。
这导致了两个相互竞争的追踪框架，从而导致了非正式的“追踪战争”。通常，竞争对最终用户来说是一件好事，因为它会孕育创新。然而，在开源规范世界中，竞争可能会导致采用、贡献和支持不佳。
回到 Kubernetes 的例子，想象一下，如果每个人都使用不同的编排解决方案，那么容器的采用会变得多么脱节和缓慢。为了避免这种情况，在巴塞罗那举行的 KubeCon 2019 上宣布，OpenTracing 和 OpenCensus 项目将合并为一个名为 OpenTelemetry 的项目，并加入 CNCF。
第一个测试版本于 2020 年 3 月发布，是继 Kubernetes 之后第二活跃的 CNCF 项目。
OpenTelemetry 组件
OTel 由几个组件组成，如下图所示。让我们从左到右对每一个进行高级查看：
上图来自 OpenTelemetry: 不止入门
APIs
这些是核心组件并且特定于语言（例如 Java、Python、.Net 等）。 API 为您的应用程序提供基本的“管道”。
SDK
这也是一个特定于语言的组件，是在 API 和导出器之间提供桥梁的中间人。 SDK 允许进行额外的配置，例如请求过滤和事务采样。
Exporter
这允许您配置要将其发送到哪个后端。导出器将检测与后端配置解耦。这使得切换后端变得很容易，而无需重新检测代码。
Collector
收集器接收、处理和导出遥测数据。虽然在技术上不是必需的，但它是 OpenTelemetry 架构的一个有益组件，因为它为接收应用程序遥测数据和向后端发送应用程序遥测数据提供了更大的灵活性。
收集器有两种部署模型：
- 与应用程序驻留在同一主机上的代理（例如，binary、DaemonSet、sidecar 等）
- 与应用程序完全分离的独立进程
由于收集器只是收集和发送遥测数据的规范，因此它仍然需要后端来接收和存储数据。
OpenTelemetry 贡献者概况
虽然 OTel 拥有一些较小的用户和个人贡献者，但大公司正在投入时间推动发展。短短一个月内，该项目的贡献总数就超过 11,000 人。Dynatrace、Splunk 和 Microsoft 均位居前 10 名贡献者之列。超过 100 家公司和供应商定期（或已经）为 CNCF 的创意做出贡献。
其背后的社区既多元化又强大。 GitHub、Slack 和 Twitter 等平台都有专门的社区或工作区。 Stack Overflow 仍然是寻找该项目答案的绝佳场所。那些寻求第一手数据的人甚至可以查阅CNCF DevStats 仪表板以获取更多信息。
OpenTelemetry 有哪些计划？
截至 2023 年 10 月，OpenTelemetry 规范的最新版本为 v1.25，包含对跟踪数据最成熟的支持。指标、日志和行李信号都在积极开发中，成熟度各不相同。
本文翻译自：https://www.dynatrace.com/news/blog/what-is-opentelemetry-2/
总结
OpenTelemetry 是一个开源可观测性框架，旨在提供统一的标准和工具，以便开发人员可以轻松地收集、生成、收集和导出遥测数据。这些数据包括日志、指标和跟踪，这些数据对于了解应用程序和基础设施的执行情况至关重要。 OpenTelemetry 通过提供统一的供应商无关库和 API 集，使得收集数据变得更加容易，从而使组织能够更容易地实施容器部署。
