分析的现状

六个多月前，OpenTelemetry 发布了性能剖析信号支持。尽管该信号仍在开发中，尚未推荐用于生产环境，但性能剖析 SIG 在多个方面取得了实质性进展。

本文总结了性能剖析 SIG 在过去六个月中取得的进展。

OTLP 改进

在v1.3.0版本中，性能剖析被添加为 OTLP 的新信号类型，但该区域仍被标记为不稳定，我们正在对其进行持续的更改。

虽然我们最初的意图是保持与 pprof 的在线兼容性，但这一目标被证明是不切实际的，因此性能剖析 SIG 已决定重构协议，不再追求与 pprof 的严格兼容性。相反，我们将致力于可转换性，这与我们为其他信号所做的工作类似。这一转变仍在进行中，并导致协议的性能剖析部分出现若干重大更改。请注意，这不会影响 OTLP 协议中构成大部分内容的稳定部分，如指标、Span、日志、资源等。

eBPF 代理改进

去年 6 月，Elastic 持续性能剖析代理的捐赠最终完成。自那时以来，opentelemetry-ebpf-profiler 存储库一直在不断进行改进。

我们 eBPF 代理的下一个目标是将其作为 Collector 的接收器运行。一旦完成，Collector 就可以作为代理运行在每个节点上，收集该主机的性能剖析数据，并通过 OTLP 进行转发。这种架构将允许我们提取代理中不完全属于性能剖析的特定部分，例如检索主机元数据和系统指标，并将它们移至处理器，从而使代理更轻量级、更模块化。

Collector 支持

自v0.112.0以来，OpenTelemetry Collector 能够接收、处理和导出性能剖析数据，并支持使用 OTLP 进行性能剖析数据的摄取和导出。

您可以尝试通过在 Collector 中启用 service.profilesSupport 功能门，并进行类似以下的配置，来摄取和导出使用 OTLP 的数据。

receivers:
  otlp:
    protocols:
      grpc:
exporters:
  otlp:
    endpoint: 'localhost:4317'
service:
  pipelines:
    profiles:
      receivers: [otlp]
      exporters: [otlp]

虽然此功能目前可以在 Collector 上使用，但我们仍不建议在生产环境中使用：它仍在积极开发中，并且预计会有重大更改，例如上面提到的 OTLP 的更改。

然而，Collector 中的这种支持意味着 Collector 的任何接收器、处理器或导出器现在都可以开始添加对性能剖析的支持，我们强烈鼓励这样做，以便将来能够更顺利地集成，以及及早发现潜在问题。如果您想报告 bug 或为此做出贡献，可以在 contrib 存储库中查看。

语义约定与规范

为了提高互操作性，性能剖析 SIG 还致力于OpenTelemetry 性能剖析语义约定。目前还在进行一项工作，旨在引入性能剖析 OpenTelemetry 规范。这项工作将继续进行，并有望实现跨不同平台、工具和其他 OTel 信号的广泛采用。

下一步计划？

OpenTelemetry 中的性能剖析支持发展非常迅速，虽然我们距离提供一个稳定的信号还有很长的路要走，但我们很高兴地报告，大家可以开始着手进行实验，并将其集成到各自的模块中。

如果您有兴趣帮助性能剖析的进步，或在集成过程中遇到问题，性能剖析 SIG 随时乐意提供或寻求帮助。

您可以在 CNCF slack 的#otel-profiles频道找到我们。

• ←上一篇
• 下一篇→