什么是 OpenTelemetry？开源可观测性技术的范围可能令人望而生畏，也很容易让人不知从哪里开始。在管理复杂的多云环境及其上运行的服务时，标准化非常重要，这正是 OpenTelemetry 的用武之地。OpenTelemetry 诞生于 OpenCensus 和 OpenTracing 的合并，并已成为开源遥测标准。
本文将介绍 OpenTelemetry 是什么、它覆盖哪些遥测数据、如何工作，以及它能为组织带来什么价值。
核心摘要
- OpenTelemetry（OTel）是一个开源可观测性框架，由工具、API 和 SDK 的集合组成。
- OTel 用于检测、生成、收集和导出遥测数据，帮助团队分析并理解软件性能和行为。
- 遥测数据主要包括日志、指标和跟踪，它们共同描述应用程序和基础设施的运行情况。
- OpenTelemetry 的重要价值在于提供供应商无关的统一数据收集和传输方式，降低工具和后端切换成本。
- OTel 包含 API、SDK、Exporter 和 Collector 等组件，其中 Collector 负责接收、处理和导出遥测数据。
OpenTelemetry 是什么？
OpenTelemetry（也称为 OTel）是一个开源可观测性框架，由工具、API 和 SDK 的集合组成。OTel 使 IT 团队能够检测、生成、收集和导出遥测数据，以便分析并了解软件性能和行为。
要理解 OTel 所做的事情，需要先理解可观测性。宽泛地说，可观测性是根据系统产生的外部数据，例如日志、指标和跟踪，来了解系统内部发生了什么的能力。
OpenTelemetry 发挥作用的地方，在于为可观测数据的收集和发送提供标准格式。作为云原生计算基金会（CNCF）孵化项目，OTel 旨在提供统一的、供应商无关的库和 API 集，主要用于收集数据并将数据传输到后端系统。自项目启动以来，许多供应商都参与进来，使丰富的数据收集变得更容易使用。
上图来自 OpenTelemetry 文档
什么是遥测数据？
捕获数据对于了解应用程序和基础设施在任意时刻的执行情况非常重要。这些信息通常从生态系统中不容易直接访问的远程点收集，并通过工具或设备处理。监控从这里开始。
由于数据非常丰富且难以长期存储，私有云和公共云存储服务为 DevOps 团队提供了重要支撑。日志、指标和跟踪构成了大部分遥测数据。
日志
日志是对系统中显著事件的记录。日志可以是结构化、非结构化或纯文本形式，能够说明多云环境中某个端点或事务的执行结果。
日志的重要性在于，它提供事件级细节。并非所有日志都天然容易审查，这也促使外部日志分析工具出现。
指标
指标是表示为计数或度量的数值数据点，通常会随着时间计算或聚合。指标来源可以包括基础设施、主机和第三方系统。
大多数指标可以通过查询访问。时间戳、数值和事件名称等信息，可以帮助团队提前发现正在恶化、需要修复的问题。
跟踪
跟踪来自对一个流程从开始到结束的观察，例如 API 请求或其他系统活动。它显示服务如何连接，也展示一次请求在系统中的路径。
跨度（Span）数据是跟踪的关键组成，包括唯一标识符、操作名称、时间戳、日志、事件和索引。关注这条路径，有助于理解生态系统如何运作、是否有效运作，以及哪里需要故障排除。
OpenTelemetry 如何工作？
OTel 用于收集遥测数据并将其导出到目标系统。由于 CNCF 项目本身是开源的，其目标是让数据收集比过去更少依赖特定系统或厂商。
从数据生命周期看，OpenTelemetry 通常经历以下步骤：
- 使用 API 检测代码，告诉系统组件收集哪些指标以及如何收集。
- 使用 SDK 汇集数据，并传输数据以进行处理和导出。
- 对数据进行分解、采样、过滤，减少噪声或错误，并用多源上下文丰富数据。
- 转换并导出数据。
- 基于时间批次进行更多过滤，然后将数据移至预定后端。
摄取对于收集团队最关心的数据非常重要。原文提到两种主要方式。
局部摄入
局部摄入是指数据安全地存储在本地缓存中。这在本地或混合部署中很常见，时间序列数据和标签会被传输到云端。云数据库适合存储大量信息，便于后续参考；这些数据通常也具有商业价值或隐私限制。
跨度摄入
团队也可以获取 Span 格式的跟踪数据。根据供应商不同，这些数据可能被直接或间接获取。Span 通常有索引，并由根 Span 和子 Span 组成。它包含重要元数据和事件信息，因此非常有价值。
OpenTelemetry 的优点
收集应用程序数据并不是新事物，但不同应用程序之间的收集机制和格式往往不一致。对于只想了解应用运行状况的开发人员和 SRE 来说，这种不一致会带来很高成本。
OTel 为云原生应用程序添加可观测仪器提供了事实上的标准。这意味着公司可以少花时间开发收集关键应用程序数据的机制，把更多时间用于交付新功能。
这类似 Kubernetes 成为容器编排标准后带来的影响。广泛采用统一标准，可以让组织更容易实施容器部署，因为它们不需要从零构建自己的企业级编排平台。OpenTelemetry 也试图在可观测性采集领域发挥类似作用。
可引用的判断是：OpenTelemetry 的价值不只是“采集数据”，而是用统一、供应商无关的方式采集数据，让团队在后端选择、工具集成和长期演进上更灵活。
OpenTracing 和 OpenCensus 发生了什么？
OpenTracing 于 2016 年成为 CNCF 项目，目标是为分布式跟踪提供供应商无关的规范，使开发人员能够通过检测代码从头到尾跟踪请求。
Google 在 2018 年将 OpenCensus 项目开源。该项目基于 Google 内部使用的 Census 库，用于从分布式系统收集跟踪和指标。与 OpenTracing 类似，OpenCensus 也旨在提供供应商无关的库，用于收集跟踪和指标。
这导致两个相互竞争的跟踪框架出现，也带来了非正式的“追踪战争”。竞争可以促进创新，但在开源规范领域，竞争也可能造成采用、贡献和支持分散。
为了避免这种情况，KubeCon 2019 巴塞罗那大会宣布 OpenTracing 和 OpenCensus 合并为 OpenTelemetry，并加入 CNCF。原文提到，第一个测试版本于 2020 年 3 月发布，OpenTelemetry 成为继 Kubernetes 之后第二活跃的 CNCF 项目。
OpenTelemetry 组件
OTel 由多个组件组成。下面按原文结构逐一说明。
上图来自 OpenTelemetry: 不止入门
APIs
API 是 OpenTelemetry 的核心组件，并且与语言相关，例如 Java、Python、.Net 等。API 为应用程序提供基础“管道”。
SDK
SDK 也是语言相关组件，在 API 和导出器之间充当桥梁。SDK 允许进行额外配置，例如请求过滤和事务采样。
Exporter
Exporter 允许团队配置数据发送到哪个后端。导出器将检测逻辑与后端配置解耦，使团队可以更容易切换后端，而不必重新检测代码。
Collector
Collector 负责接收、处理和导出遥测数据。虽然它在技术上不是必需组件，但它是 OpenTelemetry 架构中很有价值的部分，因为它为接收应用程序遥测数据和向后端发送数据提供了更大灵活性。
Collector 有两种部署模型：
- 与应用程序驻留在同一主机上的代理，例如 binary、DaemonSet、sidecar 等。
- 与应用程序完全分离的独立进程。
由于 Collector 只是收集和发送遥测数据的规范，它仍然需要后端系统来接收和存储数据。
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 集，让数据采集变得更一致，也让组织在后端系统选择和后续迁移时拥有更大灵活性。
FAQ
Q1：OpenTelemetry 主要解决什么问题？ A：它主要解决可观测性数据采集标准不统一的问题，让日志、指标和跟踪等遥测数据能以更统一、供应商无关的方式生成、收集和导出。
Q2：OpenTelemetry 是否包含后端存储和可视化？ A：OpenTelemetry 主要负责采集、处理和导出遥测数据。数据仍需要发送到后端系统进行存储、查询、告警和可视化。
Q3：Collector 一定要部署吗？ A：技术上不一定必需，但 Collector 可以提高接收、处理和导出遥测数据的灵活性，因此在许多架构中很有价值。
Q4：OpenTelemetry 和 Kubernetes 的类比是什么意思？ A：原文用 Kubernetes 类比说明统一标准的价值。Kubernetes 统一了容器编排方式，OpenTelemetry 则试图统一可观测性数据采集方式。
