Elastic 通过剖析代理增强 OpenTelemetry，向社区共享系统健康洞察功能

译者 | 张卫滨

策划 | Tina

Elastic 最近宣布计划向 OpenTelemetry（OTel）项目捐赠其持续剖析代理。该代理是一个始终在线的持续剖析解决方案，不需要运行时或字节码插装（instrumentation）、重编译、主机调试标记或重启服务。

Elastic 剖析代理使用了 eBPF 技术，是一种用于监控不同语言和环境下应用程序性能的工具。它可以对整个网络和系统进行全系统范围的持续剖析，而无需对应用程序进行任何变更或重启。它构建的栈跟踪从内核开始，经过用户空间原生代码，并扩展至在更高层级运行时执行的代码。这有助于快速定位出性能的下降，减少不必要的计算，更快地排查复杂的问题。

自 2021 年 8 月份以来，该代理一直部署在大型的客户环境中。

Elastic 是 OTel 社区的活跃成员，尤其是在剖析特别兴趣小组（Profiling Special Interest Group，SIG） 中。该小组在创建 OTel 剖析数据模型（Profiling Data Model） 方面发挥了关键作用，这是实现剖析数据标准化的重要举措。

在代码影响经济和环境的时代中，关注计算效率尤为重要。高效的软件可以降低成本，减少碳足迹。Elastic 希望通过此次捐赠支持 OpenTelemetry 社区提高计算效率。

有的时候，库或后台进程占用的资源比应用程序本身还多。有了对整个系统进行剖析的工具以及按服务和总使用量分析数据的工具，就能更容易地识别这些资源密集型的元素。与只分析运行时的传统剖析器不同，Elastic Universal Profiling 可提供完整的系统洞察力。

图片来源：OpenTelemetry 和 Elastic 互相协作为社区提供持续剖析的功能

它可以剖析从我们的代码直到第三方库和内核活动的所有内容，包括我们的所有权之外的代码。这种广阔的视角有助于定位低效的常用库并揭示 CPU 资源占用的隐藏问题，从而实现快速优化。

Elastic 剖析代理的特点包括对系统资源的影响小，测试中 CPU 使用率上限为 1%，内存使用量上限为 250MB。它为剖析原生 C/C++ 应用程序提供了强大的支持，无需 DWARF 调试信息，而是利用.eh_frame 数据进行 堆栈展开（stack unwinding）。

该代理可对缺乏帧指针和调试符号的系统库进行剖析，并支持不同运行时的混合堆栈跟踪，涵盖了从内核空间到未修改的系统库再到高级语言的所有内容。此外，即便主机上没有调试符号，它也能处理 C/C++、Rust、Zig 和 Go 等多种语言的原生代码。

关于 OpenTelemetry，我们在 Hacker News 上看到了一段有趣的对话。讨论围绕着 OpenTelemetry 的现状展开，技术社区分享了他们的见解。其中一位 HN 用户表示，虽然 OpenTelemetry 是一个很有前景的想法，但它还没有完全达到预期，尤其是文档方面的不足。入门的指南对基本设置很有帮助，但在解决更复杂的实际应用场景方面还存在不足。

Elastic 一直参与各种 OpenTelemetry（OTel）项目，包括开发语言 SDK，如 OTel Swift、Go、Ruby 等。该公司还积极参与特别兴趣小组（SIG），以强化 OTel 在可观测性和安全性标准方面的作用。

Elastic 迫切希望通过捐献剖析代理来加强与 OTel 的合作关系，从而确保 Elastic 和更广泛的 OTel 社区都能从中受益。欢迎感兴趣的人士参与提案或讨论。

查看英文原文：

Elastic Enhances OpenTelemetry with Profiling Agent, Sharing System Health Insights to the Community(https://www.infoq.com/news/2024/03/elastic-donates-profiling-agent/)

声明：本文为 InfoQ 翻译，未经许可禁止转载。