报告揭示 OpenTelemetry 对 Go 的性能影响

来自可观测性平台Coroot的一项新基准研究揭示了在高吞吐量Go应用程序中实施OpenTelemetry的性能成本。研究结果表明，尽管 OpenTelemetry 提供了宝贵的追踪级洞察，但它引入了显著的开销，使 CPU 使用率增加了约 35%，并增加了负载下的网络流量和延迟。

该研究使用一个由内存数据库支持的简单 HTTP 服务，在相同的负载条件下（每秒 10,000 个请求）比较了基线性能和完整的 OpenTelemetry 仪器性能。在四个 Linux 主机上的Docker容器中进行的运行揭示了几个发现：启用追踪使 CPU 使用量从 2 核增加到 2.7 核（大约 35%），内存使用量增加了 5-8MB，99 百分位延迟从大约 10 毫秒略微增加到 15 毫秒。此外，追踪数据导致大约 4MB/s 的出站网络流量，突出了完整请求级遥测的资源影响。

该研究还对比了基于SDK的追踪和基于eBPF的方法，尽管应该注意，因为 Coroot 销售基于 eBPF 的可观测性解决方案。eBPF 避免了修改应用程序代码，即使在仅收集指标的重负载下，资源消耗也低于 0.3 核。Coroot 得出结论，尽管 OpenTelemetry 的 SDK 提供了详细的追踪可见性，但它带来了可测量的开销，必须与可观测性需求相权衡。他们认为，对于优先考虑低延迟并使用受限资源的用例，基于 eBPF 的实现可能是一个更合适的折衷方案。

这一评估在 Go 社区引发了讨论。Hacker News上的讨论表明，可以通过优化 SDK 内部实现性能提升，如使用更快的时间函数、用原子替换互斥锁或有系统地封送。在Reddit上，用户指出即使在零抽样的情况下，由于上下文传播和跨度管理，仍然存在显著的开销。这些观点强调了一个更广泛的认可，即尽管 OpenTelemetry 带来了重要的洞察，但它也引入了需要仔细实施和调整的资源权衡。

一位用户FZambia表示：

“我最初对跟踪的开销（包括资源方面和检测过程方面）和使用参数的适当检测应用持怀疑态度。随着时间的推移，我越来越多地看到追踪帮助诊断问题、调查事件的例子。可视化在这里有很大的帮助——当你有追踪时，跨团队的沟通将大大简化。尽管如此，我还是看到跨度（span）在标签中包含了如此多不必要的数据，而在每个请求上收集它们似乎要做很多工作，而这些跨度中的 99.999%你并没有使用到。开启采样也是有争议的——当你需要时找不到跨度（有时即使请求成功也需要）。所以阅读对跟踪开销的详细调查非常有用，谢谢！”

Coroot 的基准提供了有价值的数据，表明 Go 中的 OpenTelemetry 以可测量的成本提供了强大的可观测性，大约有 35%的 CPU 开销，并在负载下增加了延迟。社区的反应表明，优化正在进行中，但是团队仍然应该平衡跟踪级可见性与性能约束的需求，并在适当时探索更轻量级的选项，如基于 eBPF 的度量指标。

原文链接：

https://www.infoq.com/news/2025/06/opentelemetry-go-performance/