作者：来自 Elastic Alexander Wert, Jack Shirazi, Jonas Kunz, Sylvain Juge
随着 Elastic 继续致力于 OpenTelemetry (OTel)，我们很高兴地宣布推出 OTel Java Agent 的 Elastic 发行版。 在这篇博文中，我们将探讨我们独特的发行版背后的基本原理，详细介绍它带来的强大的附加功能。 我们将概述如何将这些增强功能与我们的发行版、标准 OTel SDK 或标准的 OTel Java 代理一起使用。 请继续关注，我们将展望我们的未来计划，以及你对 Elastic 对 OTel Java 未来发展的贡献的期望。
OpenTelemetry Java 代理的 Elastic 发布
到目前为止，希望通过自动检测来监控其 Java 服务的 Elastic 用户有两种选择：专有的 Elastic APM Java 代理或标准的 OTel Java 代理。 虽然这两种代理都提供强大的功能并且已达到较高的成熟度，但每种代理都有其独特的优势和局限性。 OTel Java 代理提供跨广泛框架和库的广泛工具，具有高度可扩展性，并且本地发出 OTel 数据。 相反，Elastic APM Java 代理包含 OTel Java 代理所没有的多项强大功能。
Elastic 发行的 OTel Java 代理旨在将专有 Elastic Java 代理和 OpenTelemetry Java 代理的最佳方面结合在一起。 该发行版通过扩展实现的一组附加功能增强了普通 OTel Java 代理，同时仍然是完全兼容的直接替代品。
Elastic 对 OpenTelemetry 的承诺不仅侧重于标准化 OTel 周围的数据收集，还包括改进 OTel 组件并将 Elastic 的数据收集功能集成到 OTel 中。 在这种情况下，我们的最终目标是将 Elastic 发行版中的尽可能多的功能贡献给上游 OTel Java 代理； 我们的发行版的设计方式是，作为扩展实现的附加功能可以直接与 OTel SDK 配合使用。 这意味着它们可以独立于 Elastic 的发行版使用 —— 可以与 OTel Java SDK 一起使用，也可以与标准的 OTel Java 代理一起使用。 我们将在下面的部分中进一步讨论这些使用模式。
包含的功能
OpenTelemetry Java 代理的 Elastic 发行版包含一套扩展，可提供下述功能。
推断的跨度
在最近的一篇博客文章中，我们介绍了推断跨度，这是一项强大的功能，旨在通过额外的基于分析的跨度来增强分布式跟踪。
推断的跨度（上图中标记为 “内部” 的蓝色跨度）为代码中的延迟来源提供了有价值的见解，这些延迟来源可能无法通过纯粹基于检测的跟踪捕获。 换句话说，它们填补了基于检测的跟踪之间的空白。 OTel Java 代理的 Elastic 发布包括推断跨度功能。 可以通过设置以下环境变量来启用它。
ELASTIC_OTEL_INFERRED_SPANS_ENABLED=true
与分析的相关性
随着 OpenTelemetry 拥抱分析，以及 Elastic 捐赠其基于 eBPF 的连续分析代理的提议，开辟了将分布式跟踪与连续分析数据关联起来的新领域。 这种集成提供了对延迟问题和二氧化碳排放足迹的前所未有的代码级洞察，所有这些都在明确定义的服务、事务（transactions）和跟踪 (trace) 上下文中进行。 为了了解你如何从这种相关性中受益，请查看这篇博客文章，其中我们探讨了这些技术如何融合以增强软件开发中的可观察性和环境意识。
Elastic Universal Profiling 的用户已经可以利用 OTel Java 代理的 Elastic 发行版来访问这一强大的集成。 随着 Elastic 提议捐赠分析代理，我们预计所有将 OTel Java 代理与新的 OTel eBPF 分析结合使用的 OTel 用户很快就能使用此功能。
跨度堆栈跟踪
在许多情况下，分布式跟踪内的跨度相对粗粒度，特别是当不使用推断跨度等功能时。 准确理解跨度在代码路径中的起源位置非常有价值。 为了满足这一需求，OTel Java 代理的 Elastic 分发包括跨度堆栈跟踪功能。 此功能通过收集超过可配置的最小持续时间的跨度的相应堆栈跟踪来提供重要的见解，准确地指出代码中跨度的启动位置。
这一简单而强大的功能显着增强了问题故障排除能力，使开发人员能够更清楚地了解其应用程序的性能动态。
在上面的示例中，它允许你获取 gRPC 调用的调用堆栈，这可以帮助了解哪些代码路径触发了它。
自动检测服务和云资源
在当今广泛且多样化的云环境中（通常包括多个区域和云提供商），了解有关服务运行位置的信息非常有价值。 特别是在 Java 服务中，服务名称经常嵌入到部署工件中，自动检索服务和云资源信息的能力标志着可用性的重大飞跃。
为了满足这一需求，OTel Java 代理的 Elastic 分发包括针对服务和云资源的内置自动检测器，特别是针对 AWS 和 GCP，这些资源源自 OpenTelemetry Java Contrib 存储库。 此功能默认启用，可增强可观察性并简化跨各种云平台的服务管理，使其成为任何基于云的部署的关键资产。
使用 Elastic 发布的方法
OTel Java 代理的 Elastic 分发旨在满足我们用户的需求，满足各种需求和战略方法。 无论你是希望完全集成新的可观察性功能还是只是增强现有设置，Elastic 发行版都提供了多种技术途径来利用其功能。 这种灵活性确保用户可以定制代理的实施，以完全符合其特定的运营要求和目标。
直接使用 Elastic 的发行版
利用上述功能的最简单途径是采用 OTel Java 代理的 Elastic 分发作为标准 OTel Java 代理的直接替代品。 从结构上讲，Elastic 发行版充当 OTel Java 代理的包装器，保持与所有上游配置选项的完全兼容性并合并其所有功能。 此外，它还包括上述的高级功能，显着增强了其功能。 Elastic 发行版的用户还将受益于 Elastic 提供的全面技术支持，该支持将在代理实现普遍可用性后开始。 首先，只需下载代理 Jar 文件并将其附加到你的应用程序：
java -javaagent:/pathto/elastic-otel-javaagent.jar -jar myapp.jar
将 Elastic 的扩展与普通 OTel Java 代理结合使用
如果你希望继续使用普通 Otel Java 代理，但希望利用上述功能，你可以灵活地这样做。 我们提供专门为此目的设计的单独代理扩展包。 要集成这些增强功能，只需下载扩展 jar 文件并将其放入指定目录并配置 OTel Java 代理扩展目录：
1. OTEL_JAVAAGENT_EXTENSIONS=/pathto/elastic-otel-agentextension.jar
2. java -javaagent:/pathto/otel-javaagent.jar -jar myapp.jar
通过 OTel Java SDK 手动使用 Elastic 的扩展
如果你使用 OTel API 将检测直接构建到应用程序中，并依赖 OTel Java SDK 而不是自动 Java 代理，你仍然可以使用我们讨论过的功能。 每个功能都被设计为独立组件，可以与 OTel Java SDK 框架集成。 要实现这些功能，只需参考每个功能的具体描述，了解如何相应配置 OTel Java SDK：
- 使用 SDK 设置推断范围功能
- 设置与 SDK 的分析关联
- 使用 SDK 设置跨度堆栈跟踪功能
- 使用 SDK 设置资源检测器
这种方法确保你可以定制可观察性工具来满足你的特定需求，而不会影响功能。
未来的计划和贡献
我们致力于 OpenTelemetry，并且我们对 OpenTelemetry Java 项目的贡献将继续无限制。 我们不仅专注于 OTel Java 项目中的一般改进，而且还致力于确保本博客文章中讨论的功能成为 OpenTelemetry Java SDK/Agent 的官方扩展，并包含在 OpenTelemetry Java Contrib 存储库中。 我们已经贡献了跨度堆栈跟踪功能，并启动了推断跨度功能的贡献，并且我们热切期待在成功集成 Elastic 分析代理后添加分析相关功能的机会。
此外，我们的努力超出了当前的增强； 我们正在积极努力将更多功能从 Elastic APM Java 代理移植到 OpenTelemetry。 我们的项目是一个特别雄心勃勃但令人兴奋的项目，旨在实现 OpenTelemetry Java 代理的动态可配置性。 未来的增强功能将允许使用 OpenTelemetry 代理管理协议 (OpAMP) 远程动态配置 OTel Java 代理，从而提高其适应性和易用性。
我们鼓励你体验 OTel Java 代理的新 Elastic 发行版并与我们分享你的反馈。 你的见解非常宝贵，因为我们努力增强 OpenTelemetry 的功能和覆盖范围，使其更加强大且用户友好。
本文中描述的任何特性或功能的发布和时间安排均由 Elastic 自行决定。 当前不可用的任何特性或功能可能无法按时交付或根本无法交付。
原文：Introducing the Elastic distribution of the OpenTelemetry Java Agent | Elastic Blog