Grafana Labs 发布 Pyroscope 2.0，这是对这款开源持续性能分析数据库的一次全面重构。该版本于 2026 年 4 月 21 日发布，解决了原始设计中累积的存储成本、查询性能和运维复杂性问题。
持续分析与指标、日志和追踪是可观测性堆栈的四大支柱。指标可以报告高 CPU 使用率等问题，追踪可以显示哪个服务是瓶颈，而分析则更进一步，可以精确定位到具体是哪个函数的哪一行代码在消耗 CPU 资源。Grafana Labs 资深工程师 Christian Simon 在公告中写道，随着系统日益复杂，这种区分变得至关重要，因为只有在函数级别才能进行有针对性的优化，而不是简单地增加硬件资源。
“持续分析能够实时捕获这类运行瞬间，让你不必依靠调试器碰运气。”
——Christian Simon，Grafana Labs
原始 Pyroscope 基于 Cortex 构建，Mimir 和 Loki 早期版本也采用了相同的底层架构，但这三个项目后续都逐步脱离了该架构。Simon 指出，Mimir 近期完成了架构重构，去除了写入路径中的副本复制操作，实现了读写解耦，并将对象存储作为唯一的真实数据来源。Pyroscope 2.0 采用了相同的架构设计原则，并根据分析数据的特性进行了适配：大负载、大量的符号信息，以及突发的查询模式。
最显著的成本下降来自取消了写入路径中的副本复制。在 v1 版本中，每份分析数据都会被写入三次。单份分析数据大小可达数十兆字节，因此三倍的放大效应会对存储开销造成明显影响。Pyroscope 2.0 将每份分析数据只写入对象存储一次。第二个成本下降来自数据共置：把同一服务产生的分析数据集中存储，让函数名、源码位置、堆栈跟踪等符号信息能够进行去重处理。Simon 透露，在 Grafana 自己的生产环境中，这一优化最多可将符号存储占用降低 95%。
读取路径也经过了重新设计。在 v1 版本中，查询是在有状态的组件内部进行处理，而这类组件无法弹性扩容，这就意味着即便业务处于空闲时段，也必须按照峰值负载预留容量。Pyroscope 2.0 将整条读取路径改造为无状态模式：任意的查询器都能处理任意的查询，查询器数量可根据业务需求灵活调整。Simon 指出，分析数据的访问模式具备突发性，不存在稳定的基础流量，但故障发生期间会出现大量并发访问。他还发现，由大模型驱动的智能体正越来越多地调取分析数据，用于自动化问题排查，这种新型流量也从弹性扩展中受益。
“借助无状态查询器，系统能够从容应对各类流量峰值，无需在非峰值时段为闲置资源容量额外付费。”
——Christian Simon，Grafana Labs
从运维角度来看，更少的有状态组件意味着故障类型更少、部署速度更快。Simon 表示，v1 版本中需要耗时 8 至 12 小时的部署工作如今只需要几分钟就能完成。分段写入器改为无磁盘模式，存储网关组件也已被彻底移除。
新架构还启用了在 v1 版本中无法实现的新功能。这些功能包括从分析数据中衍生生成指标——可将分析数据聚合为跨服务、跨部署的集群级对比，无需逐一查询单条分析数据；支持查看单个分析数据实例，而不局限于聚合数据；以及用于可视化分析数据时间分布的热力图查询能力。Simon 表示，这些功能并非单独额外开发，而是更简洁的数据模型与无状态读取路径带来的自然成果。
此次发布恰逢持续分析作为标准可观测性信号逐步获得行业认可。OpenTelemetry 在 2024 年 8 月宣布已将持续分析纳入核心遥测信号，Elastic 将其持续分析代理捐赠给了该项目。OpenTelemetry 最近宣布其 Profiles 信号进入了 Alpha 阶段。Pyroscope 2.0 原生支持 OpenTelemetry 协议（OTLP），允许团队通过标准的 OpenTelemetry 流水线摄取分析数据。
可观测性社区早已注意到性能分析与降低成本之间的关联。InfoQ 2024 年 2 月一篇关于年度可观测性预测的文章指出，FinOps 与 OpenTelemetry 的发展、AI 技术集成一道，是塑造该领域格局的核心力量之一。这些趋势在 Pyroscope 2.0 的发布中均有所体现：架构调整大幅降低了大规模运行性能分析的成本，OTLP 协议适配紧跟 OpenTelemetry 的普及步伐，同时 Simon 也明确提到，已有 AI 智能体在生产环境中调取使用性能分析数据。
Pyroscope 并非唯一的开源持续分析项目。Polar Signals 开发了 Parca，一个用于收集持续分析数据的开源系统，使用 eBPF 实现低开销的数据采集。Polar Signals 联合创始人 Frederic Branczyk 在 InfoQ 的访谈中介绍他们使用 eBPF 和一个叫作 FrostDB 的自定义时序数据库同样解决了 Pyroscope 2.0 通过架构重构解决的存储与查询难题。
在商业替代方案方面，Datadog、New Relic、Dynatrace 和 Sentry 都为偏好托管解决方案的团队提供了替代选择。CubeAPM 也提供了持续分析功能，作为全栈可观测性平台的一部分，面向希望简化部署、降低运维开销的企业组织。Pyroscope 采用开源代码结合 Grafana Cloud Profiles 托管服务的模式，使其与这些厂商形成差异化定位，尤其适合已经在使用其他 Grafana 生态组件的团队。
Pyroscope 的实际应用案例有充分的文档记录。在 2026 年伦敦 QCon 大会上，Monzo 的工程师分享他们使用 Pyroscope 进行持续分析，以便在部署时检测性能回归，同时他们还维护了一个叫作“Graph Trending Downwards”的 Slack 频道，用于记录性能改进的情况。InfoQ 在 2026 年 3 月报道了这次演讲。Uber 也发布了在 Go 语言中运用配置文件引导优化（Profile-Guided Optimisation）的详细实践，这一工作流程在 2025 年 3 月的 InfoQ 文章中有详细记录，Grafana Labs 也提到自己在同样的流程中使用了 Pyroscope。
Grafana Cloud Profiles 是由 Pyroscope 驱动的托管版本，自 2025 年 4 月起已在生产环境中运行 2.0 架构。Grafana 在 2025 年 9 月将其推广到所有区域，此后累积已处理 19.5PB 的分析数据。对于现有的 Grafana Cloud Profiles 用户，迁移工作已全部完成。对于自行运行 Pyroscope 的团队，从 v1 版本升级的关键变化是分布式部署需要依赖对象存储，因为它现在是所有分析数据的唯一真实数据来源。迁移指南和发布说明可在项目文档中获取。
查看英文原文：https://www.infoq.com/news/2026/05/pyroscope-2-profiling/
