过去，性能剖析（profiling）多是工程师在线上出现 CPU 飙高或内存泄漏时，临时接入的一次性动作：抓一段火焰图，定位到某个热点函数，改完代码再把探针撤掉。随着采样精度提高、单机开销被压到个位数百分比以内，以及可观测性数据模型逐步统一，持续剖析正在从按需排查变成生产环境长期常开的基础设施。

为什么现在能常开

第一个变化来自采集方式。基于 eBPF 的内核态采样可以在不修改应用、不重启进程的前提下周期性抓取调用栈，对 Java、Go、Python、Node.js 等运行时都能给出相对可比的栈信息；语言自带的 pprof、JFR 等接口则负责补齐托管运行时内部的细节。相比早期依赖字节码注入或调试符号的方案，这类采集对延迟和吞吐的影响明显下降，常见实现给出的额外 CPU 开销多在百分之一上下。

第二个变化是数据模型的收敛。OpenTelemetry 把 profiles 列为与 traces、metrics、logs 并列的第四类信号，并在近两年持续推进规范落地，pprof 等格式被广泛接受。这意味着剖析数据可以和链路追踪共享服务名、Pod 名、版本、可用区等标签，工程师从一条慢调用直接下钻到对应的函数级火焰图，而不必在多个系统之间手工对齐时间戳。

生产环境里的新用法

  • 容量与成本：把 CPU、内存火焰图按服务、版本聚合，找出占用资源却收益有限的代码路径，为降配和调度提供依据。
  • 发布门禁：把剖析结果接入发布流程，新版本上线后资源画像若明显偏移即触发告警。
  • 常态化对比：按天、按周留存基线，区分偶发抖动与持续劣化，避免问题积累到事故才被发现。

仍需解决的问题

常开并不等于零成本。栈数据的基数很高，长期留存会迅速推高存储与查询开销，多数团队会采用分层策略：原始栈只保留小时级或天级，聚合后的指标化画像长期保存。符号化也是难点，编译器优化、动态生成代码和容器镜像精简都可能让栈难以还原，需要在构建期就产出并托管符号表。此外，栈信息中可能包含函数名、参数甚至业务标识，跨团队共享前需要脱敏与权限控制。

对多数云上团队而言，持续剖析的价值不在于多一个仪表盘，而在于把资源究竟花在哪里变成可随时查询的事实。当采集开销足够低、数据模型足够统一，它就会像指标一样成为默认开启的能力，推动性能治理从被动救火转向持续优化。