APM Profile 在系统可观测体系中的应用
![APM Profile 在系统可观测体系中的应用](https://static001.geekbang.org/infoq/52/52201dff26cfca6c6368c95a1b1446c1.png)
引言
应用程序性能分析(Application Performance Management,APM)是一个广泛的概念,涉及应用程序运行时各种性能指标的监测、诊断和优化。在可观测体系建设中,APM 是保障系统业务运行性能的关键技术,确保用户可以借助可观测技术手段,感知并发现以往监控工具难以发现的应用运行过程中隐藏的问题。
应用性能分析的主要场景
当我们应用观测云系统进行分析和监控时,采集到的应用性能数据通常有以下几种使用场景:
性能监测(Performance Monitoring):通过 Datakit 提供的各种 dk-apm-agent,实时收集对应开发语言所发布的应用程序运行过程中的性能数据,包括应用指标、应用 span 数据等。这些原始性能数据为后续的性能分析和优化提供基础。
性能分析(Performance Analysis):借助 Guance Studio 可视化应用分析界面,对收集到的性能数据进行深入分析。通过火焰图、瀑布图等应用性能数据组织方式,用户可以快速的识别应用程序的性能瓶颈所在,为性能优化提供依据。
性能优化(Performance Optimization):根据 APM 应用性能监测的分析结果,用户可以采取针对性的代码优化措施,包括重构、算法替代、运行时环境配置调整等方式,提升应用程序的整体性能表现。
性能预警(Performance Alarming):针对已分析处理的应用性能问题场景,在 GuanceStudio 中配置持续监控应用程序性能的监控器,一旦发现异常情况能够及时生成告警,通知对应的问题关注人进行处理。
性能报告(Performance Reporting):借助 GuanceStudio 场景功能的可视化仪表构建能力,用户可以方便的将性能数据以可视化方式呈现,生成性能报告供开发、运维人员分析和决策使用。
上述 APM 数据应用及分析场景环环相扣,构成了应用程序性能管理整体流程的闭环。而对于某些需要更细粒度性能分析的场景,就需要用到 APM 的另一项核心技术—应用性能 Profile 功能。
Profile 与 APM 的区别
相比 APM 数据源针对应用链路的数据采集,Profile 功能在采集方式、数据颗粒度及适用场景方面与 APM 数据有着一定的区别:
侧重点不同:APM 是一个更广泛的概念,涵盖了从性能监测、分析、优化到监控的全生命周期管理。而 Profile 功能更专注于应用程序内部结构和运行机制的深入分析,为性能优化提供诊断依据。
采集数据范围不同:APM 通常会采集应用程序、基础设施、用户体验等各方面的性能数据,以全面了解应用程序的性能表现。而 Profile 工具主要关注应用程序内部的 CPU、内存等指标。
实现机制不同:APM 通常会采用轻量级的探针或代理程序收集性能数据,而 Profile 工具则需要深度介入应用程序的运行机制,通常会对应用程序的性能产生一定影响。
![](https://static001.geekbang.org/infoq/5d/5d16da586091cd9ce5fa69cf6e23cf6a.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
总体而言,Profile 功能是 APM 体系中不可或缺的组成部分,它为应用程序的性能优化和监控提供了更细粒度的数据支持。而不同类型的开发语言通过各自不同的方式生成并采集 Profile 数据,例如 Java 可使用 JVM 提供的工具——如大家熟知的 Java Flight Recorder (JFR)——对 Java 应用程序的各种性能指标进行采集和分析;Python 使用 Python 自带的 cProfile 模块进行性能分析。Go 语言自带了丰富的性能分析工具,如 pprof 命令行工具和 runtime/pprof 包等。下面以 Java 为例进一步拓展讨论 Profile 数据的生成、采集及应用场景。
Profile 数据的生成和采集
Java Profile 功能的实现,离不开 Java 虚拟机提供的 Profiler 接口。Java 虚拟机从早期的 JVMPI(Java Virtual Machine Profiler Interface)到后来的 JVMTI(Java Virtual Machine Tool Interface),为 Profile 工具的开发者提供了强大的支持。
JVMPI 是 Java 1.3 版本引入的一个 profiler 接口,它允许 profiler 代理程序在 Java 虚拟机运行时收集各种性能数据,如 CPU 时间、内存使用情况、线程状态等。profiler 代理可以通过 JVMPI 接口注册各种事件回调,在这些事件发生时获取相关的性能数据。
但同时 JVMPI 接口也存在侵入性强、跨平台兼容性较差的问题。为了解决这些问题,在 Java 1.5 版本引入了全新的 JVMTI(Java Virtual Machine Tool Interface)。JVMTI 是一个更加通用和灵活的 profiler 接口,具有以下特点:
更加轻量级和低侵入性,profiler 代理可以选择性地监控感兴趣的事件,降低对应用程序性能的影响。
接口设计更加简洁清晰,开发 profiler 代理程序的难度降低。
跨平台兼容性更好,不同版本和不同厂商的 Java 虚拟机对 JVMTI 的实现更加统一。
![](https://static001.geekbang.org/infoq/f1/f1a36374f0388bf80f3dcfd12131f478.png)
借助 JVMTI,Java 虚拟机为各种 profiler 工具的开发提供了强大的支持。这些 profiler 工具能够深入 Java 应用程序的内部结构,全面收集性能数据,为开发者进行性能分析和优化提供有力支撑。
而当我们需要采集 Profile 数据时,首先需要激活或应用一定的数据采集探针。以观测云为例,我们需要在程序启动时引入观测云应用性能数据采集器 guance-java-agent,这是一个基于前述 JVMTI 接口机制开发的应用性能数据采集器,可采集包含 Tracing 和 Profiling 数据在内的各种应用性能数据。
![](https://static001.geekbang.org/infoq/a1/a1848b4e08bdaf8039bc4f323ecb9050.png)
在配置 guance-java-agent 并启动 Java 应用程序时,被注入的性能监测代码会实时收集各种性能相关的数据。这些数据主要包括以下几种类型:
CPU 这个指标记录了应用程序在 CPU 上的使用情况,包括 CPU 利用率、CPU 时间消耗等。通过分析 CPU 使用情况,可以发现 CPU 密集型的操作,比如计算量大的方法,从而进行针对性的优化。
Allocations 记录了应用程序在运行过程中发生的对象分配情况。分析这个指标可以了解应用程序的内存使用模式,发现可能存在的内存泄漏问题。
Allocated Memory 记录了应用程序在运行过程中分配的内存总量。结合 Allocations 指标一起分析,可以发现内存使用是否过高,是否存在内存泄漏等问题。
Heap Live Objects 记录了 Java 虚拟机堆中存活的对象数量。监控这个指标可以发现内存占用过高,以及垃圾回收是否频繁等问题。
Heap Live Size 记录了 Java 虚拟机堆的实际占用大小。这个指标可以反映应用程序的整体内存使用情况。
Wall Time 记录了应用程序的总体响应时间。通过分析这个指标,可以了解应用程序的整体性能表现。
Class Load 记录了应用程序在运行过程中加载的类的情况。分析这个指标可以发现类加载瓶颈,以及是否存在类冲突等问题。
Thrown Exceptions 记录了应用程序在运行过程中抛出的异常情况。分析异常信息有助于快速定位并解决应用程序的故障。
File I/O 记录了应用程序在文件读写操作方面的性能数据。通过分析这个指标,可以发现 I/O 瓶颈,并针对性优化文件操作。
Lock 记录了应用程序在使用锁方面的情况,包括锁竞争、锁等待时间等。分析这个指标有助于发现并解决应用程序中的并发问题。
Socket I/O 记录了应用程序在网络 I/O 操作方面的性能数据,如连接时间、读写时间、吞吐量等。通过分析这个指标,可以发现网络 I/O 瓶颈,并针对性优化网络操作。
![](https://static001.geekbang.org/infoq/a4/a49e29b058e6cf149d4a5d769c52e8bd.png)
这些数据在采集后会被发送至观测云中心,经中心处理后形成 APM 应用性能监测页的 Profile 数据记录,用于性能问题分析。需要注意的是上述部分指标依赖特定的 Java 版本,如发现没有采集到对应的数据,可以首先关注一下当前您所使用的 Java 版本是否提供了这些数据。
Profile 数据的应用
在完成数据采集后,我们可以基于 Profile 功能提供的详细性能数据,对系统中存在的一些潜在性能问题进行分析。这里分享一个某零售行业客户的性能分析 profile 案例:
某线上零售公司在近期针对自研大数据推荐平台的迭代中发现,新上线版本的推荐功能,其响应时延随 QPS 上升会出现比较明显的响应时间瓶颈。由于该系统采用微服务架构部署,其跨服务的性能问题分析一直是公司难以解决的一个痛点。在引入观测云 APM 并开启 Profile 功能后,基于已采集的数据分析并尝试优化该推荐系统的对外服务性能。
在整体的分析过程中,我们首先通过观测云 DataKit 指标采集,定位到具体发生 CPU 负载过高的节点,再通过应用负载监控,确定推荐系统中 CPU 负载过高的功能模块。开启 profile 后可以看到随着负载增加,有若干代码方法其 CPU 占比占到总 CPU 时间的 60% 左右。咨询客户开发团队,该方法主要负责根据商品的特征(如价格、销量、评分等)计算两件商品之间的相似度。其代码实现使用了大量的计算和排序操作。
![](https://static001.geekbang.org/infoq/8c/8c66ed8584624d218ac5ba8d117fc4a1.png)
同时,观察 Allocations 这项 Profile 指标,发现在高峰时段内存分配速率明显增加,峰值达到每秒 x 万次以上。同时比对 guance-java-agent 提供的 JVM metrics,结合 Profile Heap Live Objects 和 Heap Live Size 变化,发现有大量的临时对象在不断创建和销毁,造成频繁的 GC 操作。结合前述代码逻辑判断,此代码逻辑在计算和排序时创建了大量的临时缓存对象或排序数组。虽然这些临时对象在方法执行完后会被销毁,但频繁的创建和销毁过程造成了较高的内存分配开销和 GC 压力。并进一步使高并发条件下的服务响应时间恶化。而这些现象在静态代码走读或低负载条件下的集成测试或功能测试过程中是很难暴露的,从而造成代码性能缺陷漏出到生产环境,影响用户的使用和体验。
![](https://static001.geekbang.org/infoq/31/31bab1c2f7321025fd41d1c96802903b.png)
将上述分析结果告知具体模块的开发负责人后,通过针对性的优化措施,例如优化相似商品筛选算法、优化临时对象复用、减少临时对象创建和销毁操作、缓存相似商品计算结果等措施后,系统性能得到了明显改善。高并发下的系统响应时间也明显缩短。有效提升了最终用户的产品使用满意度。
总结
除 Java 语言外,观测云也结合其他开发语言的特点,为开发者及用户提供了对应改语言的 Profile 数据采集功能,对应用代码执行过程中的 CPU 使用情况、内存使用情况、锁使用情况、网络 IO、文件 IO、线程使用情况等多个方面的数据进行采集。并通过 Guance Studio 对这些丰富的性能数据进行可视化分析。借助火焰图、瀑布图等展示手段,用户可以深入了解应用程序的运行状况,找出性能瓶颈,并进行针对性的优化。这就是 APM Profile 给开发者带来的巨大价值。
评论