OpenTelemetry 项目路线图

OpenTelemetry 是一个健康的开源社区，贡献者可以自由地提出新的工作流或在他们喜欢的项目的任何部分工作。然而，项目通过聚焦特定工作内容和发布来团结社区成员也具有价值，这使得我们能够形成一套更具凝聚力的功能（统一的语义、每种语言的单一实现等），并以更具影响力的方式发布项目（例如，跨多种语言同时发布新的信号类型等）。

此路线图并非“法律”，也不用于强制人们从事特定项目——这是一个开源项目，我们（社区成员、治理委员会等）都不是任何人的老板。相反，它旨在为新贡献者、希望了解后续进展的公众和最终用户提供方向，并努力将我们大部分的关注和开发精力引导到最需要这些领域。

我们取得的成就

OpenTelemetry 于 2019 年启动，承诺通过 SDK、Collector 和 OTLP 使开发人员能够轻松一致地从应用程序和基础架构中捕获分布式跟踪和指标。自那时以来，我们已交付了：

  • 分布式跟踪和指标的规范，它定义了用于表示每种数据的对象、如何与它们交互以及期望的来自不同来源的数据类型。
  • 元数据的语义约定，它定义了资源和其他组件的表示方式。这会跨所有信号类型一致地应用，从而允许跟踪、指标和其他信号被一致地处理和关联。
  • 支持十二种语言的 SDK，允许开发人员从其服务中捕获遥测数据并创建自己的自定义遥测数据。
  • 支持 __ 种语言的自动仪器，允许任何人无需更改代码或重新部署即可从其服务中捕获遥测数据。
  • 为数千种软件（包括操作系统、容器运行时、数据库、语言运行时和库）提供的仪器库，这些库允许 Collector（用于基础架构和第三方应用程序）以及 SDK 和自动仪器代理（用于自定义应用程序）自动捕获信号、捕获元数据和传播上下文。
  • 一种协议 OTLP，用于在 OpenTelemetry 组件之间以及与后端之间传输遥测数据和元数据以进行处理。

主要优先事项

以下所有工作流都是 OpenTelemetry 的主要投资领域：它们都有大量人员已经关注。它们的优先级主要反映了我们期望它们发布的时间顺序。

当将这些优先级相互比较时，它们最有价值。例如，P0 条目比 P1 条目更关键，而 P1 条目又比 P2 条目更关键。我们确实对每个优先级级别有一些基本定义，但

  • P0：我们必须在指定的时间范围内（如果有时限）完成这项工作，否则我们将作为项目失败。
  • P1：这是我们最重要的主要举措之一，它将对项目产生重大影响。
  • P2：这项工作足够重要，值得跟踪和优先处理，并且比此列表之外的项目更重要，但目前其紧急程度或重要性低于 P0 和 P1 条目。

P0：持续投入 OpenTelemetry 制品

项目的首要任务始终是确保我们现有制品（Collector、SDK、语言代理等）的能力和健壮性保持卓越。这项工作在每个语言 SIG 和 Collector SIG 中进行，包括对这些组件的持续改进，使它们更易于使用，提供和集成更多仪器库，与遥测源的供应商合作以原生使用 OpenTelemetry API，等等。

P1：日志

OpenTelemetry 于 2020 年中期成立了日志 SIG，有两个目标：

  1. 为捕获现有日志源（通常是磁盘上的文本文件）提供高性能的路径，所有捕获的日志都将一致地应用 OpenTelemetry 的元数据。
  2. 为新应用程序提供一个全新的、强类型且性能极高的日志捕获路径，该路径允许在不进行文本解析的情况下编写和传输日志，并强制所有元数据的一致性。

第一个目标已经取得了很大进展，特别是通过将 Stanza 日志代理捐赠给 OpenTelemetry Collector，以及项目在定义和稳定日志的数据模型和 OTLP 格式方面所做的投入。然而，在我们宣布日志工作普遍可用之前，仍有许多工作要做：

  • 我们必须扩展 Collector 对现有日志源的支持，以满足更多用户的需求。
  • Elastic 将 Elastic Common Schema 捐赠给了 OpenTelemetry 的语义约定。我们必须将其完全集成。
  • 我们必须在 SDK 中原型化新的日志捕获路径，根据原型化工作的反馈更新设计，为现有日志组件和遥测源构建集成，在所有语言中实现这些设计（就像我们对跟踪和指标所做的那样），并测试和修订这些从 Beta 到 GA 的实现。

P1：进一步稳定语义约定

OpenTelemetry 在所有数据类型中一致的语义约定是该项目价值的主要来源，因为它们允许最终用户和可观察性系统同时关联相关信号，并对从特定源或交互类型捕获的遥测数据应存在的元数据设定预期。例如，OpenTelemetry 的语义描述了作为 HTTP 4xx 响应一部分捕获的跟踪、指标和日志的预期元数据。

然而，我们仍需为更多场景定义语义约定，以便仪器作者可以发布稳定的仪器库，以便最终用户和可观察性系统可以对 OpenTelemetry 的元数据做出更可靠的依赖。

P2：客户端仪器（RUM）

我们希望 OpenTelemetry 为服务所有者提供真正的端到端可见性，包括端到端延迟（包括客户端应用程序和互联网延迟）以及从一次用户交互开始发生的后端服务事件和基础架构端性能统计数据的链条。这要求 OpenTelemetry 开始支持网页 JavaScript、移动应用程序和桌面应用程序。OpenTelemetry JS 自其首个版本发布以来，在技术上支持从 Web 浏览器捕获 span，但这种行为在很大程度上是不明确的，而且对于其他类型的客户端应用程序（如 Android、iOS 或 Windows 上的应用程序）没有等效功能。

2021 年末，成立了客户端仪器 SIG（通常称为 RUM SIG），该 SIG 致力于规范客户端仪器行为，以确保不同类型客户端应用程序中捕获的数据以及面向开发者的遥测接口保持一致。该 SIG 目前正在完成其第一轮规范工作，完成后将需要由 JS、Swift、Java 等 SIG 实现。

P2：性能剖析

分布式性能剖析一直是 OpenTelemetry 中长期讨论的话题，其他性能剖析项目的贡献者一直倡导将其作为一种额外的信号类型添加到 OpenTelemetry 中。2022 年 5 月，这项工作在 OpenTelemetry 的性能剖析 SIG 中启动。

采样堆和 CPU 剖析将允许 OpenTelemetry 将最终用户的可见性扩展到其实际代码的性能。虽然其他性能剖析解决方案今天允许这种检查，但很少有能够正确地将剖析与应用程序和基础架构资源元数据相关联，甚至更少能够将性能剖析遥测与分布式跟踪或其他信号相关联。将其添加到 OpenTelemetry 将允许分析解决方案和最终用户找到服务之间的性能不佳的实例，然后立即将其追溯到代码中的根本原因。

P2：OpenTelemetry 演示

OpenTelemetry 于 2022 年 5 月启动了一个社区演示 SIG，该 SIG 将提供演示 OpenTelemetry 功能的示例应用程序给潜在的最终用户，并允许社区更好地对 OpenTelemetry 组件进行自动化测试。该项目的第一版于 2022 年 10 月发布，我们将在 2023 年及以后继续在这方面投入。

P2：OpenTelemetry 控制平面

自 OpenTelemetry 启动以来，最终用户和供应商一直希望（a）了解其环境中部署了哪些 SDK、语言代理和 Collector（以及它们的状态），以及（b）能够更改这些制品的配置，甚至可能更新代理二进制文件。

规范工作已在进行中以解决这两个需求，OpAMP SIG 已经发布了驱动这些交互的协议 OpAMP 的规范。随着时间的推移，开发各种 OpenTelemetry 制品的 SIG 将需要实现 OpAMP 以支持这些场景。

待办事项

这些主题过去曾被讨论过，但要么被刻意排在项目主要正在进行的优先事项之下，要么还没有形成大量贡献者支持。

  • eBPF 仪器（由一小部分贡献者正在为 Collector 进行中）。
  • 生产调试 / 动态日志注入。
  • 自动配置 Collector 以捕获更多来源的数据。
  • 捕获来自 CI / CD 系统的遥测数据（带有适当的语义）。
  • 描述云支出和云资源使用对环境影响的语义。
  • 增强 OpenTelemetry 语义约定的用户/组织可扩展性。