如果您开发应用程序，您可能听说过 OpenTelemetry。在 Elastic®，我们对 OpenTelemetry 作为标准化应用程序检测和可观察性的未来充满热情。
在本文中，我们将分享我们计划通过引入 OpenTelemetry 语言 SDK 的 Elastic 发行版来扩展我们对 OpenTelemetry 的采用和承诺，这将补充我们现有的 Elastic APM 代理。
什么是 OpenTelemetry？
OpenTelemetry 是一个供应商中立的可观察性框架和工具包，支持应用程序和分布式微服务架构中的跟踪、指标和日志等遥测信号。
在一些标准的推动下，OpenTelemetry 旨在为检测和观察应用程序行为提供一致的方法。OpenTelemetry 是在云原生计算基金会（CNCF）保护伞下开发的孵化项目，目前是第二活跃的项目，仅次于 Kubernetes。
您可以访问 OpenTelemetry 网站，了解有关采用 OpenTelemetry 的概念、术语和技术的更多信息。
更丰富的检测环境
通过采用 OpenTelemetry，软件代码可以以与供应商无关的方式进行检测，遥测信号以标准化格式导出到一个或多个供应商后端，例如 Elastic APM。其设计为应用程序所有者提供了灵活性，可以在不更改代码的情况下切换供应商后端，并使用 OpenTelemetry 收集器 将遥测数据发送到多个后端。
由于 OpenTelemetry 不是特定于供应商的解决方案，因此语言生态系统更容易采用它并提供强大的检测。供应商不再需要自己实现特定的检测。OpenTelemetry 是一种标准，库开发人员有兴趣引入和维护所有消费者都可以从中受益的检测。
因此，有更多可用的检测库，并且可以更好地保持更新。如果您的公司拥有开源库，您还可以贡献和创建您自己的检测，以便您的客户更容易采用 OpenTelemetry 并从其应用程序中更丰富的跟踪、指标和日志记录中受益。
Elastic 和 OpenTelemetry
Elastic 深入参与 OpenTelemetry。2023 年，我们捐赠了 Elastic 通用模式，该模式正在与 语义约定 合并。2024 年，我们正在捐赠我们基于 eBPF 的 分析代理。我们还在整个组织中向 OpenTelemetry 的各个领域贡献了多个贡献者。
因此，我们致力于帮助 OpenTelemetry 取得成功，这意味着，在某些情况下，开始放弃特定于 Elastic 的组件，并建议改用 OpenTelemetry 组件。
Elastic 致力于支持和贡献 OpenTelemetry。我们的 APM 解决方案已经接受本地 OTLP（OpenTelemetry 协议）数据，我们的许多 APM 代理已经桥接了使用 OpenTelemetry API 检测的应用程序的数据收集和传输。
我们旅程的下一步是引入语言 SDK 的 Elastic 发行版，并通过向 OpenTelemetry SDK 存储库贡献代码，向上游的 OpenTelemetry 社区捐赠功能。
什么是 OpenTelemetry 发行版？
OpenTelemetry 发行版 只是一个或多个 OpenTelemetry 组件的自定义版本。每个发行版都扩展了组件提供的核心功能，同时遵守其 API 和现有功能，并利用内置的扩展点。
Elastic OpenTelemetry SDK 发行版
随着 OpenTelemetry SDK 的 Elastic 发行版的发布，我们正在扩展我们对 OpenTelemetry 的支持，使其成为检测应用程序的首选和推荐选择。
OpenTelemetry 维护和发布许多语言 API 和 SDK，用于使用 OpenTelemetry 观察应用程序。API 为检测应用程序代码提供了特定于语言的接口，而 SDK 实现了该 API，从而可以收集和导出观察到的应用程序中的信号。
我们目前的工作扩展了 OpenTelemetry 语言 SDK，以引入其他功能，并确保导出的数据与我们当前的后端提供最强大的兼容性，同时它会发展为更本地化的 OpenTelemetry。
其他功能包括重新实现目前在 Elastic APM 代理中可用但不是 OpenTelemetry SDK 一部分的概念。发行版允许我们为所有已知提供与 Elastic 的可观察性产品最佳集成的信号提供有主见的默认值。
毫无疑问，可以使用 OpenTelemetry API 来检测代码，然后引用 OpenTelemetry SDK 来启用应用程序生成的跟踪、指标和日志数据的收集。Elastic APM 接受本地 OTLP 数据，因此您可以配置 OpenTelemetry SDK 将遥测数据直接导出到 Elastic 后端。我们将此设置称为使用“vanilla”（又名“本地”）OpenTelemetry SDK。
我们正在努力改进对在我们的后端本地存储和呈现 OpenTelemetry 数据的支持，以便我们可以直接从来自各种遥测信号的数据驱动我们的可观察性 UI。我们的工作重点是确保 Elastic 精选的 UI 可以无缝处理 ECS 和 OpenTelemetry 格式。除了这项工作之外，我们还在开发语言 SDK 的发行版，以支持希望在其应用程序中采用 OpenTelemetry 本地检测的客户。
当前的 Elastic APM 代理支持诸如集中配置和跨度压缩之类的功能，这些功能目前不属于 OpenTelemetry 规范。我们正在投入我们的工程专业知识，通过将其贡献给 OpenTelemetry，将这些功能带给更广泛的受众。由于标准化需要时间，我们可以通过提供发行版，更快地将这些功能带给 OpenTelemetry 社区和我们的客户。
我们认为，负责任的选择是专注于启用和鼓励客户在代码中支持与供应商无关的检测，并获得 OpenTelemetry 的好处。
发行版最能满足我们完全采用并推荐 OpenTelemetry 作为观察应用程序的首选解决方案的决定。通过提供目前在“vanilla”OpenTelemetry SDK 中不可用的功能，我们可以支持希望在其应用程序中采用 OpenTelemetry 本地、与供应商无关的检测的客户，同时仍然提供他们今天使用现有 APM 代理所享受的相同的功能集和后端功能。通过维护 Elastic 发行版，我们还可以更好地为客户提供增强和修复，而无需考虑“vanilla”OpenTelemetry SDK 的发布周期，我们认为这是选择它们的关键差异化因素。
我们的愿景是，Elastic 将与 OpenTelemetry 社区合作，通过标准化流程捐赠功能，并贡献代码以在本地 OpenTelemetry SDK 中实现这些功能。随着时间的推移，我们希望看到许多 Elastic APM 代理独有的功能过渡到 OpenTelemetry，直到不再需要 Elastic 发行版为止。与此同时，我们可以通过我们的 OpenTelemetry 发行版提供这些功能。
然后，应用程序开发人员有多种选择来检测和收集其应用程序中的遥测数据
-
Elastic APM Agent： 功能最全，但特定于供应商
-
带有 OpenTelemetry Bridge 的 Elastic APM Agent： 供应商中立的检测 API，但存在已知限制
- 仅支持桥接追踪（不支持指标）
- 不支持 OpenTelemetry span 事件
-
OpenTelemetry “原生” SDK： 今天完全支持； 但是，它缺少 Elastic APM Agent 的一些功能，例如 span 压缩
-
Elastic OpenTelemetry 发行版
- 默认支持供应商中立的检测，代码中没有 Elastic 特有的配置
- 当使用 Elastic Observability 作为后端时，建议使用默认设置
- 使用 OpenTelemetry API 来进一步自定义我们的默认设置； 无需学习新的 API
虽然我们将在可预见的未来继续支持所有用于检测代码的选项，但我们认为，通过引入第四个 OpenTelemetry 原生产品，我们正在为客户的成功奠定基础。我们预计这将随着时间的推移成为 Elastic 客户首选的默认设置。
我们目前针对 .NET 和 Java 的发行版处于 alpha 发布状态，其他语言发行版也即将推出。我们鼓励您查看这些存储库，试用这些发行版，并通过问题向我们提供反馈。您宝贵的意见使我们能够改进我们的设计并指导我们的方向，以确保我们的发行版让消费者满意。
了解我们针对 .NET 的 OpenTelemetry SDK 新 Elastic 发行版的 alpha 版本。
本帖中描述的任何特性或功能的发布和时间安排均由 Elastic 自行决定。任何当前不可用的特性或功能可能无法按时交付，甚至根本无法交付。