作者：来自 Elastic Christos Kalkanis，Florian Lehner 及 Roger Coll
OpenTelemetry Profiles 已正式达到 Alpha 阶段，将性能分析确立为第四种可观测性信号。Elastic 的核心贡献包括其 eBPF 性能分析代理、持续的 OpenTelemetry Profiles 信号工作以及对厂商中立生态系统的承诺，推动这一行业标准向前发展。
在 Elastic 与 OpenTelemetry 社区的密切合作下，我们非常高兴地宣布，OpenTelemetry Profiles 信号已正式进入公共 Alpha 阶段。此里程碑彰显了社区的奉献精神，并标志着在 OpenTelemetry 中将性能分析确立为继日志、指标和追踪之后的第四个关键可观测性信号的重要一步。
作为核心贡献者，Elastic 自豪地通过此前向 OpenTelemetry 捐赠其基于 eBPF 的 Universal Profiling™ 持续性能分析代理，加速了这一进程。该生产级代理能够对整个系统的所有应用提供可视化，覆盖多种编程语言和运行时，包括第三方库和内核操作，同时开销极小。它让 SRE 和开发人员能够快速识别性能瓶颈、最大化资源利用率，并优化云端成本。
此外，在过去两年中，Elastic 大力参与了 OpenTelemetry Collector、Semantic Conventions 以及 Profiling 特别兴趣小组（SIGs）的工作，为 Profiles 晋级 Alpha 打下了技术基础。
这一 Alpha 里程碑不仅促进了持续性能分析的标准化，也加速了将性能分析作为可观测性第四关键信号的实际应用。客户现在拥有一种厂商中立的方式来收集性能分析数据，并将其与现有信号（如日志、指标和追踪）进行关联，从而揭示新的可观测性洞察潜力，并提供更高效的问题排查体验。
什么是持续性能分析？
性能分析是一种通过收集应用执行信息来理解软件行为的技术，包括跟踪函数调用的持续时间、内存使用、CPU 使用及其他系统资源。
然而，传统性能分析解决方案存在显著缺点，限制了在生产环境中的应用：
-
由于代码插桩导致的高成本和性能开销
-
需要中断服务重启
-
无法获取第三方库的可视性
与传统性能分析通常仅在特定开发阶段或受控测试环境中进行不同，持续性能分析在后台以最小开销运行，无需服务重启或人工干预。它提供实时且可操作的洞察，无需在独立环境中复现问题。SRE、DevOps 和开发人员可以看到代码如何影响性能和成本，从而更容易改进代码和基础设施。
Elastic 的贡献：驱动 Alpha
Elastic 捐赠的性能分析器现在成为 OpenTelemetry 中基于 eBPF 的参考性能分析器实现：opentelemetry-ebpf-profiler。随着 Alpha 版本发布，该 eBPF 性能分析器作为 OpenTelemetry Collector 接收器运行，并包含多项改进，例如自动 Go 符号化以及对新语言运行时的支持。作为 OpenTelemetry Collector 接收器运行，使性能分析器能够无缝利用现有的 OpenTelemetry 处理和过滤管道。
例如，k8sattributesprocessor 可以使用 container.id 资源属性自动为每个分析数据丰富其对应的 Kubernetes 上下文。这意味着你看到的不仅是原始堆栈跟踪，而是能够准确知道是哪一个命名空间、Pod 和部署产生的。
`
1. receivers:
2. # Profiling receiver
3. profiling: {}
5. processors:
6. k8sattributes:
7. passthrough: false
8. pod_association:
9. - sources:
10. - from: resource_attribute
11. name: container.id
12. extract:
13. metadata:
14. - "k8s.namespace.name"
15. - "k8s.deployment.name"
16. - "k8s.replicaset.name"
17. - "k8s.statefulset.name"
18. - "k8s.daemonset.name"
19. - "k8s.node.name"
20. - "k8s.pod.name"
21. - "k8s.pod.ip"
22. - "k8s.pod.uid"
`AI写代码
除了对 eBPF 性能分析器的改进之外，Elastic 在以下方面也做出了重要贡献：
-
将性能分析数据与 OpenTelemetry eBPF 插桩（OBI）生成的信息关联，OBI 是一个强大的自动插桩工具，可启用分布式追踪。
-
进程上下文共享 OTEP，旨在弥合应用 SDK 与性能分析器之间的差距。该机制允许 OpenTelemetry SDK “发布”它们的资源属性（如 service.name）到一个小型标准化内存区域。由于这些数据存储在进程自身的内存映射中，eBPF 性能分析器可以立即发现并将其与对应的 Profile 关联。
-
语义约定及 OpenTelemetry Profiles 与 Google 的 pprof 格式的集成（透明转换）
-
OpenTelemetry Collector 处理管道，使其更好地与性能分析接收器集成
Elastic 下一代性能分析开发
Elastic 继续深度支持 OpenTelemetry 的愿景，并推动性能分析数据的潜力边界。我们专门组建了一支性能分析领域专家团队，共同维护和提升 OpenTelemetry 中的性能分析能力，同时开发基于这一新开放标准的创新功能。
内部针对性能分析的开发重点包括：
-
OpenTelemetry Profiles 派生指标：我们正在开发创新方法，从原始 OTel Profiles 数据中自动生成可操作的性能指标，为基础设施建模和告警提供新维度。
-
与 Elastic Stack 的快速集成：我们在 Elastic Stack 中为 OTLP Profiles 提供一流支持，确保该新信号能够与现有日志、指标和追踪无缝整合，包括采集（ebpf-profiler 接收器已与 Elastic 分发的 OpenTelemetry (EDOT) Collector 集成）、存储和可视化。
-
AI 驱动工作流：利用持续性能分析数据提供的深度洞察，实现自动根因分析、异常检测以及对代码和基础设施的智能优化建议。
虽然 Alpha 发布标志着一个重要里程碑，但这仅是开始。我们鼓励社区尽早测试 OTel Profiles 集成的预览版本，并参与持续的性能分析工作。要开始实际的本地部署，你可以将 OpenTelemetry eBPF 性能分析器与自托管的 Elastic Observability Stack 或 devfiler（独立桌面应用，作为 OpenTelemetry Profiles 兼容后端，用于实验和开发）结合使用。
