Elastic 将其持续分析代理贡献给 OpenTelemetry

在 Elastic 和 OpenTelemetry 的分析社区 进行了大量合作，包括一个全面的审查过程后，我们很高兴地宣布 OpenTelemetry 项目已接受 Elastic 捐赠的持续分析代理。

这标志着将分析作为 OpenTelemetry 的核心遥测信号建立起来的一个重要里程碑。Elastic 的 基于 eBPF 的 分析代理以低 CPU 和内存开销在生产环境中观察不同编程语言和运行时、第三方库、内核操作以及系统资源的代码。SRE 和开发人员都可以受益于这些能力：快速识别性能瓶颈，最大化资源利用率，减少碳排放，并优化云支出。

Elastic 决定将该项目贡献给 OpenTelemetry，是为了加速 OpenTelemetry 的使命，并通过高质量、可移植的遥测实现有效的可观测性。此次合作也体现了对供应商中立和社区驱动开发的承诺，从而增强了整体的分析和可观测性生态系统。

此次捐赠是通过 Elastic 和 OpenTelemetry 社区之间富有成效的合作完成的。我们期待共同将持续分析确立为 OpenTelemetry 的一个组成部分。

随着今天的接受，Elastic 的持续分析代理将被贡献给 OpenTelemetry。该代理现在将由 Elastic 团队以及来自不同公司的各种官方维护者共同支持。

• Dmitry Filimonov (Grafana Labs)
• Felix Geisendörfer (Datadog)
• Jonathan Halliday (Red Hat)
• Christos Kalkanis (Elastic)

什么是持续分析？

持续分析是一种通过收集软件应用程序执行信息来理解其行为的技术。这包括跟踪函数调用时长、内存使用、CPU 使用以及其他系统资源以及相关的元数据。

持续分析的优势

传统的分析解决方案，通常用于一次性、开发时间优化，存在显著的缺点，限制了在生产环境中的应用。

• 代码插桩会导致显著的成本和性能开销
• 服务重启中断
• 无法可视化第三方库

然而，持续分析在后台运行，开销极小，提供实时、可操作的见解，而无需在单独的环境中复制问题。

这使得 SRE、DevOps 和开发人员能够看到代码如何影响性能和成本，从而更容易进行代码和基础设施的改进。

贡献全面的分析能力

Elastic 捐赠的持续分析代理 基于 eBPF，是一种完整的系统、始终开启的解决方案，可以观察代码和第三方库、内核操作以及您不拥有的其他代码。它消除了代码插桩（运行时/字节码）、重新编译或服务重启的需要，在生产环境中具有低开销、低 CPU（约 1%）和内存使用率。

捐赠的分析代理有助于识别非最优代码路径，发现“未知之未知”，并提供对所有应用程序运行时行为的全面可视化。持续分析代理支持广泛的运行时和语言，例如

• C/C++
• Rust
• Zig
• Go
• Java
• Python
• Ruby
• PHP
• Node.js / V8
• Perl
• .NET

对 OpenTelemetry 的好处

此次贡献不仅促进了持续分析在可观测性方面的标准化，还加速了其作为 OpenTelemetry 关键信号的采用。客户可以受益于一种供应商中立的方法来收集分析数据，并将其与现有的信号（如追踪、指标和日志）相关联，从而为可观测性见解开辟新的可能性，并提供更有效的故障排除体验。

OpenTelemetry 分析的用户收益

基于 OpenTelemetry 的持续分析为用户解锁了以下可能性

• 持续分析数据通过提供有关服务行为的详细代码级见解，对现有信号（追踪、指标和日志）进行补充。

• 与追踪等其他 OpenTelemetry 信号无缝关联，提高保真度和调查深度。

• 估算环境影响：将分析数据与 OpenTelemetry 的资源信息（即资源属性）相结合，可以推断出服务碳足迹的见解。

• 通过对服务资源利用率的详细 breakdown，分析数据提供了有关性能优化机会的可操作信息。

• 提高供应商中立性：基于 eBPF 的供应商中立分析代理消除了对专有代理的需求，以收集分析遥测。

通过这些优势，SRE、开发人员和 DevOps 可以管理云端应用程序的整体效率，同时确保他们的工程团队对其进行优化。

下一步，OpenTelemetry 分析 SIG（Elastic 是其成员之一）将共同努力，将捐赠的代理集成到 OpenTelemetry 的组件生态系统中。我们期待很快为用户提供一个完全集成且可用的新 OpenTelemetry eBPF 分析代理版本。

• ←上一篇
• 下一篇→