OpenTelemetry 宣布支持性能剖析
博客文章在发布后不会更新。这篇文章已经发布一年多了，其内容可能已过时，部分链接可能无效。在依赖任何信息之前，请务必核实。
2023年，OpenTelemetry 宣布其日志、指标和追踪（Traces）已达到稳定状态。虽然这是我们项目成立之初的初步目标，但要实现构建云原生应用程序内置可观察性的愿景，就需要我们与社区共同发展。今年，我们很自豪地宣布，在性能剖析 SIG（Special Interest Group）于2022年在瓦伦西亚的 KubeCon + CloudNativeCon 上成立整整两年后，我们通过合并一个性能剖析数据模型 OTEP，并致力于在今年实现稳定规范和实现，朝着这个目标迈出了重要一步！
OpenTelemetry 性能剖析信号的这一里程碑标志着性能剖析 SIG 内部的协作努力，其中来自各种性能剖析供应商和最终用户的投入至关重要。这包括社区成员的实质性贡献，例如
- Felix Geisendörfer (Datadog)
- Alexey Alexandrov (Google)
- Dmitry Filimonov (Grafana Labs)
- Ryan Perry (Grafana Labs)
- Jonathan Halliday (Red Hat)
SIG 的集体努力一直专注于就最适合的性能剖析数据格式达成一致，社区内部的积极讨论和提案证明了这一点。
在此之前达到的一些里程碑包括：
- 性能剖析愿景对齐（2022年8月）
- 提案 v1 性能剖析数据模型（2023年9月）
- 提案 v2 性能剖析数据模型（2023年11月）
所有这些都在塑造 OpenTelemetry 性能剖析能力的未来方向和发展方面发挥了至关重要的作用。这些社区主导的讨论和贡献突显了项目的包容性和协作性承诺，确保利用广泛的见解和专业知识来推动 OpenTelemetry 的发展。
什么是性能剖析？
性能剖析是一种在运行时动态检查应用程序代码行为和性能的方法。持续性能剖析可以深入了解代码级别的资源利用情况，并允许对这些性能剖析数据进行存储、查询和分析，跨时间和不同的属性。这是开发人员和性能工程师理解代码内部具体情况的重要技术。OpenTelemetry 的 性能剖析信号 扩展了在该领域所做的工作，并且作为行业首创，将性能剖析与来自应用程序和基础设施的其他遥测信号连接起来。这使得开发人员和运维人员能够将跨服务的资源耗尽或糟糕的用户体验与不仅仅是受影响的具体服务或 Pod，而且是导致此问题的最负责任的函数或代码行相关联。
我们很高兴看到行业对这一愿景的拥抱，许多组织齐聚一堂，共同定义性能剖析信号。更具体地说，以下两项捐赠正在进行中：
- Elastic 承诺捐赠 其专有的基于 eBPF 的性能剖析代理1
- Splunk 已开始 捐赠其基于 .NET 的性能剖析器 的流程
这些捐赠是为了加速 OpenTelemetry 性能剖析的交付和实现。
这对用户意味着什么？
性能剖析将支持与日志、指标和追踪等其他信号之间的双向链接。您将能够轻松地从资源遥测跳转到相应的性能剖析。例如：
- 指标到性能剖析：您将能够从 CPU 或内存使用率的峰值，追踪到消耗该资源的具体代码部分
- 追踪到性能剖析：您将能够不仅了解服务之间的延迟位置，而且当延迟是由代码的某些部分引起时，它将反映在附加到追踪或 Span 的性能剖析中
- 日志到性能剖析：日志通常会提供存在问题的上下文，但性能剖析将允许您从仅仅跟踪某项内容（例如，内存不足错误）转变为查看哪些代码部分正在占用内存资源
这只是一部分示例，而且这些链接也可以反向工作，但总的来说，性能剖析通过让用户能够以最少的额外代码/精力来查询和理解应用程序的一个全新维度，从而更容易地实现可观察性的承诺。
蓬勃发展的社区
这项工作离不开每天致力于 OpenTelemetry 的贡献者。我们最近突破了一个新的里程碑，每月有超过 1000 名独特的开发人员为该项目做出贡献，代表着超过 180 家公司。在我们最受欢迎的仓库中，OpenTelemetry 每月有超过 3000 万次下载2，并且新的开源项目正以稳定的速度采用我们的标准，包括 Apache Kafka，以及 数十个其他项目。我们还在深化与其他 CNCF 内外开源项目的集成，例如 OpenFeature 和 OpenSearch，以及我们与 Kubernetes、Thanos、Knative 等项目的现有集成。
2024 年对于 OpenTelemetry 来说将是又一个重要的一年，我们将继续实现和稳定我们现有的追踪、指标和日志信号，同时增加对性能剖析、客户端 RUM 等的支持。现在是参与的绝佳时机！要了解更多信息，请查看 网站的其余部分。