腾讯云 APM 应用诊断升级：链路追踪与智能剖析的融合

在某电商平台的监控大屏前，弥漫着紧张的气氛，运维工程师们目不转睛地关注着实时跳动的交易成功率数据，随时准备着系统扩容。

最近一周以来，公司的业务量迎来了大幅增长，交易成功率这个关键业务指标在每天晚上 8 点至 9 点都会出现明显的波动。

APM 系统的链路追踪视图清晰地呈现着一个重要的信息：交易系统的风控服务在这个时间段存在严重性能问题，CPU 使用率峰值达到 80% 以上，导致平均响应时间超过 5 秒，以及交易失败率超过 3% 。系统扩容只能小幅度缓解交易失败问题，每个新扩容的实例在运行几分钟之后又会进入 CPU 使用率飙升的状态。

让技术团队深感困惑的是，风控服务的业务逻辑并不复杂，即使在测试环境中随数倍于生产环境的流量，表现也非常平稳。性能问题很可能和某一段业务代码的实现方式有关系，只有在特定的条件下才会被触发。APM 提供的分布式链路追踪能力没有办法覆盖所有的业务代码，这导致问题的排查一度陷入到了僵局。

这个故事并非个例，在微服务架构和容器化部署的浪潮中，应用架构呈现出显著的复杂性。一个用户请求不仅涉及多个服务节点，跨越容器、虚拟机等多种环境，还经过了多种异步编程框架。内存泄漏、锁竞争等底层性能问题往往被上层业务逻辑掩盖，导致问题根因极其隐蔽，无法被传统的监控手段捕捉。

分布式链路追踪的价值与边界

分布式链路追踪在现代分布式系统中具有至关重要的作用，在应用性能管理以及系统性能优化中被广泛使用。如果我们能够充分了解分布式链路追踪技术最擅长的领域以及局限性，就能够最大程度地发挥这项技术的价值。

当我们有如下需求的时候，可以借助分布式链路追踪解决问题：

• 梳理服务依赖：分布式系统中服务之间的依赖关系复杂，分布式链路追踪能够清晰地展示这些依赖关系，形成可视化的链路图。这有助于开发人员和运维人员更好地理解系统架构，在进行系统升级、扩展或故障处理时，能够更准确地评估影响范围，避免因对服务依赖关系不清楚而导致新的问题。
• 跨服务请求追踪以及故障快速定位：分布式链路追踪能够清晰呈现请求在多个不同服务之间的流转路径，可明确每个服务在处理请求时的先后顺序和依赖关系。当系统出现故障时，分布式链路追踪技术能依据链路信息迅速确定故障发生在哪个服务或哪个环节，大幅度缩短故障排查时间。 例如在一个金融交易系统中，若用户反馈交易失败，通过查看分布式链路追踪数据，可快速判断是交易处理服务出现异常，还是与第三方支付平台的对接环节出了问题。
• 服务性能宏观评估：分布式链路追踪可以从整体上对各个服务的性能进行评估，获取每个服务的响应时间、吞吐量等指标，方便运维人员快速定位哪些服务存在性能问题，以及这些问题对整个系统的影响程度。 比如在一个在线教育平台中，通过分布式链路追踪发现视频播放服务的平均响应时间较长，导致用户观看视频时有卡顿现象，进而可针对性地对该服务进行优化。

与此同时，分布式链路追踪也存在一系列的局限性：

• 代码级盲区：分布式链路追踪依赖埋点插桩机制，无法深入到应用内部的代码层面，不能精确分析具体函数、方法的执行时间和调用频率，更无法得知函数内部各代码块的具体执行情况。
• 缺乏系统内部视角：分布式链路追踪主要关注服务间的调用关系和外部性能指标，缺乏对系统内部状态信息的有效监控，如 CPU 使用率、内存占用、线程状态等。
• JVM 黑箱：对于内存泄漏、锁竞争、线程死锁、垃圾回收等 JVM 内部的深层次问题，分布式链路追踪无法直接感知，需要依赖其他诊断工具。
• 异步场景上下文丢失：面对云原生应用普遍使用异步框架，比如 Netty、Reactor，链路追踪技术难以精确捕捉异步任务的上下文切换和资源竞争问题。

因此，在复杂的分布式系统运维中，分布式链路追踪技术发挥着不可或缺的作用，能快速定位常规问题。但分布式链路追踪技术不是解决性能问题的银弹，我们需要借助其他技术作为补充，从而实现对复杂问题的精准排查。

性能剖析:解码云原生应用基因

在宏观视角上，分布式链路追踪技术被广泛运用，但正是由于分布式链路追踪所存在的局限性，专注于从微观视角探索云原生应用的性能剖析技术应运而生。在这种背景下，单一的诊断工具已无法满足需求。开发者需要建立分层诊断体系，将宏观的调用链分析与微观的代码级诊断相结合。

随着性能剖析技术的发展，一系列关键技术难题也被突破：

• 非侵入式诊断：无需修改代码，通过硬件计数器（如 CPU PMC）或 eBPF 技术采集数据，比如以 100Hz 采样率生成火焰图，并确保性能开销小于 1% 。
• 异步栈重建：性能剖析工具可以穿透 CompletableFuture 等异步线程池屏障，还原完整执行路径，解决异步任务上下文丢失问题。
• JVM 内核级解析：性能剖析工具可以突破应用层限制，深入 JVM 底层机制，比如精确分析具体对象的创建堆栈，发现某对象频繁创建导致的 PermGen 空间溢出，并结合火焰图识别 Full GC 频繁触发原因。

如下列举出了部分常用的性能剖析工具：

方案：一键直达代码级问题根因

尽管性能剖析技术发展很快，但主流的开源性能剖析工具都存在操作复杂，学习成本高的问题。

以 async-profiler 为例，其功能繁多，界面设计复杂，开发者特别是专业运维团队难以快速上手。而且这些工具生成的报告，充斥着专业术语和技术数据，缺乏业务视角的解读，开发者很难从中获取有价值的信息。

此外，开源性能剖析工具在性能和稳定性上存在不足，在高并发场景下，部分工具数据采集会导致系统性能下降，影响业务正常运行。

为了解决这些问题，腾讯云应用性能监控（APM）重磅发布了智能剖析方案。

通过引入智能诊断调度引擎、动态采样算法、AI 诊断决策引擎等关键技术，为开发者提供了零使用门槛，低性能开销的性能剖析方案。腾讯云性能剖析可以直接输出性能优化建议，并提供增强版火焰图等功能强大的性能分析工具，帮助用户快速定位应用性能瓶颈。

腾讯云应用性能监控（APM）是功能强大的应用性能管理平台，基于实时的多语言应用探针全量采集技术，提供分布式应用性能分析和故障自检能力，全方位保障系统的可用性和稳定性。

智能性能剖析之旅

腾讯云应用性能监控（APM）已经内置了智能性能剖析能力，只需要几个简单的步骤，就可以体验到智能性能剖析强大功能。

使用前提

• 运行环境需要安装 OpenJDK 或其他基于 HotSpot JVM 开发的 JDK，暂不支持仅安装了 JRE 的环境。
• 支持 Linux（x64, arm64）以及 macOS 操作系统，暂不支持 Windows。

1、应用接入 APM

腾讯云应用性能监控（APM）提供零代码侵入的接入方案，在安装腾讯云增强版 OpenTelemetry Java 探针后，通过修改应用的 JVM 启动参数，就可以接入 APM。

以探针路径为 /path/to/opentelemetry-javaagent.jar，应用名为 myService，业务系统 Token 为 myToken，接入点为 http://pl-demo.ap-guangzhou.apm.tencentcs.com:4317 为例，完整的 JVM 启动命令如下所示：

其中，业务系统 Token 和接入点可以从 APM 控制台获取。

对于部署在 Kubernetes 的应用，APM 提供自动接入方案，可以实现探针自动注入，方便应用快速接入。您可以参考 K8s 应用快速接入 完成接入流程。使用该方案，只需要在应用工作负载的 YAML 文件中添加 2 行，就能完成接入 APM 的全部流程。

以名为 my-app 的应用为例，需要添加至工作负载的 YAML 文件的代码片段如下所示：

接入完成后，进入 APM 控制台，应用性能监控 > 应用列表 中将展示接入的应用。

1.png

2、创建剖析任务

在 APM 控制台左侧导航栏中选择 应用性能监控 > 应用诊断，进入性能剖析（新版）页面。在页面左侧的实例列表中找到需要进行性能剖析的应用实例，单击发起任务，页面将展示如下对话框：

2.png

在弹出对话框中，根据实际需要调整采集类型、采集时长、目前时间，以及执行次数，单击确认，就能提交剖析任务。

在剖析任务执行的过程中，由于腾讯云 APM 引入了动态采样等技术，对于应用的性能影响极低（额外 CPU/内存开销在 1% 以内），因此您完全可以忽略剖析任务对于正常业务的影响，在必要的情况下，可以创建重复执行任务，对目标应用实例进行持续剖析。

3、查看剖析结果

剖析任务提交后，可以在页面右侧查询剖析结果，当采集状态为采集完成时，单击剖析结果，就能在弹出页面中查看性能剖析结果。剖析结果一共包含5个模块，通过不同的标签页进行展示：

案例分析

通过 APM 提供的告警能力，用户发现微服务架构中部分应用存在异常。在 APM 控制台中，能够清晰地获取每个应用的健康状态，以及吞吐量、响应时间、错误率等关键性能指标。其中部分应用表现为较高的响应时间，以及远超预期的调用错误率。

3.png

通过链路追踪能力，可以定位到存在问题的应用，但由于分布式链路追踪的埋点不能覆盖应用中的所有方法/函数，无法进一步定位问题根因。

4.png

在这种情况下，APM 提供的性能剖析能力就能为定位问题根因发挥关键的作用。进入到性能剖析页面，我们能够明确得知：存在问题的应用包含 2 个实例，它们都表现为非常高的 CPU 利用率，结合分布式链路追踪的分析结果，问题很有可能跟某一个业务逻辑的代码实现有关。

5.png

由于性能剖析工具已经内置于增强版探针中，我们可以直接基于 APM 控制台，对其中的一个应用实例发起剖析任务。由于应用的 CPU 使用率比较高，我们将采样类型设置为 CPU 采样分析。为了更好地排查问题根因，我们将采样时长设置为 30 秒，并重复执行 5 次。

6.png

任务执行完成后，可以在 APM 控制台查阅剖析报告。最值得关注的是分析建议栏目，在大多数场景下，该栏目可以直达问题根因。在该案例中，我们可以快速得知OopOopIterateDispatch 这个业务方法对 CPU 的影响比较大，存在进一步优化的空间。

7.png

在火焰图栏目中，我们可以精细地分析应用中不同函数的性能开销。火焰图是一种用于可视化程序性能数据的强大工具，是一个由多个矩形条堆积而成的图形，每一层矩形条代表一个函数调用栈中的函数（在 Java 等语言中，函数可以等同于方法）。

水平方向表示函数的性能开销，基于不同的采样类型进行衡量，越宽表示性能开销越大。以 CPU 采样分析为例，矩形条的宽度代表函数的 CPU 占用情况。需要注意的是，性能开销通过函数在抽样中出现的频率来体现，并不是绝对值，所以需要重点关注它们之间的相对占比。

垂直方向表示函数调用栈的深度，最下面的函数是当前正在执行的函数，向上依次是它的调用者。

通过观察火焰图中宽度较大的矩形条，可以快速定位到程序中性能开销较大的热点函数。

这些热点函数通常是优化的重点对象，因为它们的性能改进可能会对整个程序的性能产生较大影响。沿着火焰图的垂直方向，可以分析函数之间的调用关系，了解哪些函数调用了热点函数，以及它们的调用频率和执行时间分布，有助于深入理解程序的执行流程和性能瓶颈所在。

在分析火焰图时，建议从深度最深的函数开始分析。栈最深，出现在火焰图中的位置会越靠近下方，也就是“火苗”的位置（不同于自然界的火焰，在 APM 目前使用的火焰图中，火焰朝向下方）。苗越宽，代表性能上的消耗越大，所以宽火苗往往是引发性能问题的根源。

通过火焰图，进一步验证了之前的猜想，OopOopIterateDispatch 这个业务方法确实是导致该应用 CPU 使用率高的根源。

8.png

在某些场景中，还可以基于调用图栏目对底层性能问题进一步分析。调用图和火焰图比较类似，同样能够体现每个函数在整个程序执行过程中的相对性能开销占比。

和火焰图不同的是，当一个函数有多个调用方时，调用图更能够体现出函数之间的调用关系。但调用图不能通过矩形的宽度直观展示性能开销，因此大多数场景下，调用图都是配合火焰图来使用。

9.png

热点函数 AI 智能分析

经过前面的步骤，我们已经找到了引发 CPU 高使用率的业务代表片段，那到底应该如何优化呢？APM 内置 AI 性能分析引擎，基于规则引擎 + LLM 的混合架构，能够自动识别代表中的异常模式，生成代码优化建议。

10.png

通过智能诊断与自动化优化的深度结合，腾讯云 APM 解决了传统监控工具排查代码级疑难问题效率低、门槛高的问题，更通过 AI 技术实现了从被动响应到主动预防的跨越，帮助开发者快速定位并解决应用性能问题。

总结与展望

分布式链路追踪是宏观视角的导航工具，而智能剖析是微观视角的手术刀。二者结合可覆盖从服务调用到代码实现的全维度诊断，尤其在复杂异步架构和 JVM 性能问题场景中不可或缺。APM 工具需通过集成此类深度分析能力，才能真正满足现代云原生应用的故障定位需求。

腾讯云 APM 将持续突破诊断技术边界，并积极探索 AI 技术在性能诊断领域的价值。在今年，腾讯云 APM 的智能诊断能力将覆盖非 Java 应用以及更多通用的通用场景，可观测 AI 助手也将贯穿整个 APM 产品，服务于每一个细分功能，让智能诊断和 AI 技术成为您的专属性能优化专家，为云原生应用构建坚不可摧的性能保障体系。

联系我们

如有任何疑问，欢迎加入官方技术交流群

关于腾讯云可观测平台

腾讯云可观测平台（Tencent Cloud Observability Platform，TCOP）基于指标、链路、日志、事件的全类型监控数据，结合强大的可视化和告警能力，为您提供一体化监控解决方案。满足您全链路、端到端的统一监控诉求，提高运维排障效率，为业务的健康和稳定保驾护航。功能模块有：

• Prometheus 监控：开箱即用的 Prometheus 托管服务；
• 应用性能监控 APM：支持无侵入式探针，零配置获得开箱即用的应用观测能力；
• 云拨测 CAT：利用分布于全球的监测网络，提供模拟终端用户体验的拨测服务；
• 前端/终端性能监控 RUM：Web、小程序、iOS、Android 端等大前端质量、性能监控； Grafana 可视化服务：提供免运维、免搭建的 Grafana 托管服务；
• 云压测 PTS：模拟海量用户的真实业务场景，全方位验证系统可用性和稳定性；
• ......等等