作为第二大活跃的云原生计算基金会 (CNCF) 项目，OpenTelemetry 正在成为普遍使用的、统一的可观测性标准和框架。OpenTelemetry 的成功在于其全面且功能丰富的工具集，使用户能够轻松地从其应用程序中检索有价值的可观测性数据。OpenTelemetry Java 代理是 OpenTelemetry 生态系统中最成熟和功能最丰富的组件之一。它为基于 JVM 的应用程序提供自动检测，并包含针对流行的 Java 框架和库的大量自动检测模块。
OpenTelemetry Java 代理中使用的原始检测方法使自动检测模块的维护和开发受到一些限制。作为我们对 OpenTelemetry 加强承诺的一部分，Elastic® 帮助改进和完善 OpenTelemetry 项目和组件。 Elastic 对 Elastic 通用模式的贡献 对开源社区来说是一个重要的步骤。作为我们对 OpenTelemetry 承诺的又一步，Elastic 开始为 OpenTelemetry Java 代理做贡献。
Elastic 基于 invokedynamic 的检测方法
为了克服上述在开发和维护 OpenTelemetry Java 代理中的自动检测模块的局限性，Elastic 于 2023 年 7 月开始将其invokedynamic-based 检测方法 贡献给 OpenTelemetry Java 代理。
为了解释改进之处，您应该知道，在 Java 中，对应用程序进行自动检测的一种常用方法是利用在运行时进行字节码检测的 Java 代理。Byte Buddy 是一种流行且广泛使用的实用程序，它有助于进行字节码检测，而无需直接处理 Java 的字节码。从目标应用程序的代码收集可观测性数据的检测逻辑存在于所谓的“advice 方法”中。Byte Buddy 提供了将这些 advice 方法挂钩到目标应用程序方法的不同方法。
- Advice 内联：advice 方法的代码被复制到已检测的目标方法中。
- 静态 advice 分派：已检测的目标方法调用静态 advice 方法，这些方法需要被已检测的代码可见。
- 使用 _ invokedynamic __ 的 advice 分派：已检测的目标方法使用 JVM 的 invokedynamic 字节码指令来调用与已检测的代码隔离的 advice 方法。
我们在关于Elastic 的 Java APM 代理使用 invokedynamic的相关博文中详细描述了这些不同的方法。简而言之，advice 内联和分派到静态 advice 方法这两种方法在编写和维护 advice 代码方面都存在一些局限性。到目前为止，OpenTelemetry Java 代理一直使用advice 内联进行其字节码检测。开发检测的由此产生的限制在相应的开发者指南中有所记录。除其他事项外，无法调试 advice 代码的限制在开发和维护检测代码时是一个令人头疼的限制。
Elastic 的 APM Java 代理多年来一直在使用其invokedynamic 方法及其优势——经数千名客户现场验证。为了帮助改进 OpenTelemetry Java 代理，Elastic 开始贡献invokedynamic 方法，目标是简化和改进自动检测模块的开发和可维护性。贡献建议和实现概述在此 GitHub 问题中进行了更详细的记录。
随着新方法的到位，Elastic 将帮助迁移现有的检测，以便 OTel Java 社区可以从基于invokedynamic 的检测方法中受益。
Elastic 原生支持 OTel，并拥有众多功能来帮助您使用 OTel 分析您的应用程序。
使用 OpenTelemetry 进行检测
本文中描述的任何功能或功能的发布和时间安排完全由 Elastic 自行决定。任何目前不可用的功能或功能可能无法按时或根本无法交付。