腾讯云可观测平台 应用诊断

一、操作前提

二、操作步骤

1. 登录 腾讯云可观测平台。

2. 在左侧菜单栏选择 应用性能监控 > 应用诊断。

3. 在页面顶部的过滤器选择目标地域、业务系统和应用。

4. 在页面左侧的实例列表中选择目标实例。

5. 通过页面右侧的标签页选择诊断能力。

三、JVM 分析

JVM 分析包括如下表：

四、性能剖析 2.0

性能剖析能力通过智能分析引擎直接输出性能优化建议，并提供增强版火焰图等强大的可视化分析工具，帮助用户快速定位应用性能瓶颈。性能剖析目前支持 Java 和 Go 应用。其中，Java 应用的性能剖析能力基于 async-profiler 技术实现，Go 应用的性能剖析能力基于 pprof 技术实现。腾讯云增强版 OpenTelemetry Java 探针以及腾讯云 OpenTelemetry-Go 探针已经内置性能剖析能力，不依赖任何其他组件，即可以以极低的性能开销，采集剖析数据。

五、创建采集任务

1. 单击创建采集任务。

2. 在弹出对话框中，根据需要调整采集类型等选项，单击确认。

六、剖析结果

采集完成之后，控制台将展示剖析结果。剖析结果包含5个模块，通过不同的标签页进行展示。

七、剖析记录

在有多个剖析结果的情况下，控制台默认展示最新的剖析结果。你可以单击剖析记录，查看其他任务的剖析结果。

八、Go 应用内存采样分析

针对 Go 应用内存采样分析，APM 将剖析结果通过 Heap（堆）和 Goroutine（协程）两种维度进行展示。两个维度对应的内存空间说明如下：

·Heap（堆）：多个协程共享的内存空间。

·Goroutine（协程）：每个协程私有的轻量级内存空间。

其中，热点函数、火焰图和调用图功能支持独立的标签页展示两种维度的剖析结果。分析建议功能将两种维度的剖析结果合并到同一个标签页进行展示，若在某个维度未检测到明显瓶颈，对应的性能优化建议为空。

九、火焰图

火焰图中水平方向矩形条宽度表示函数性能开销，垂直方向表示调用栈深度。通过观察宽矩形条可快速定位热点函数进行优化，沿垂直方向则可分析调用关系，深入理解执行流程和性能瓶颈。在分析火焰图时，建议从深度最深的函数开始分析。栈最深，出现在火焰图中的位置会越靠近下方，也就是“火苗”的位置（不同于自然界的火焰，在 APM 目前使用的火焰图中，火焰朝向下方）。苗越宽，代表性能上的消耗越大，所以宽火苗往往是引发性能问题的根源。

在火焰图的使用过程中，可以关注如下两类指标数据：

·总计占比：表示从函数调用栈的最底层到当前函数（包括当前函数及其所有子函数）的性能开销的占比。这个数据反映了当前函数及其整个调用路径在整个程序执行过程中的相对重要性。

·自身占比：指当前函数自身的性能开销，不包括它调用其他函数的性能开销。这个指标可以帮助开发者了解当前函数本身的性能开销，而不受到其调用的其他函数的影响。

单击火焰图中的矩形条，火焰图中将只展示在垂直方向上处于该矩形条调用路径上的矩形条。在这种情况下，该矩形条可以被称为所选区域，而整个应用进程所占的区域可以被称为整体区域（也就是最上层的 root 矩形条）。因此，总计占比和自身占比都可以基于所选区域或整体区域来计算。单击最上层的 root 矩形条，可以回到火焰图的初始状态，在这种情况下，整体区域等同于所选区域。

十、调用图

调用图和火焰图比较类似，同样能够体现每个函数在整个程序执行过程中的相对性能开销占比。和火焰图不同的是，当一个函数有多个调用方时，调用图更能够体现出函数之间的调用关系。但调用图不能通过矩形的宽度直观展示性能开销，因此大多数场景下，调用图都是配合火焰图来使用。

十一、Arthas 分析

Arthas 能在不修改应用代码的情况下，对应用性能进行诊断，包括查看方法调用的出入参、异常，监测方法执行耗时，类加载信息等，大大提升线上问题排查效率。腾讯云增强版 OpenTelemetry Java 探针已经内置 Arthas 能力，关于 Arthas 控制台的操作，请参考 项目主页。

十二、线程分析

线程分析是应用诊断中用于排查线程层面问题的专用页签。它提供了当前应用实例的实时线程快照，帮助你快速定位线程死锁、线程堆积（卡死）、CPU 飙高对应的热点线程等线上问题，将问题直接关联到具体的代码行。

十三、创建采集任务

1. 单击创建采集任务。

2. 在弹出对话框中，单击确认。

十四、分析报告

采集完成后，控制台将展示分析报告，包括如下模块：

十五、线程池分析

线程池分析功能可以展示应用核心线程池的各项关键指标，包括最大线程数、核心线程数、活跃线程数、线程池任务数、线程池大小等。

十六、支持的线程池

·Apache Dubbo 2.7+

·Apache Tomcat 7.0+

·OkHttp 2.x/3.x/4.x

十七、指标明细

·最大线程数：对应 ThreadPoolExecutor.getMaximumPoolSize()

·核心线程数：对应 ThreadPoolExecutor.getCorePoolSize()

·活跃线程数：对应 ThreadPoolExecutor.getActiveCount()

·线程池大小：对应 ThreadPoolExecutor.getPoolSize()

·线程池任务数：对应 ThreadPoolExecutor.getQueue().size()

·线程池使用率：活跃线程数/最大线程数*100%

十九、支持的连接池

·Apache Druid 1.0+

·HikariCP 3.0+

·Redisson 3.0+

·Jedis 3.0+

·Lettuce 5.0+

·Apache HttpClient 4.4+

·OkHttp 2.x/3.x/4.x

20、指标明细

以 Druid 连接池为例，APM 会采集如下指标：

·当前连接数：对应 DruidDataSource.getPoolingCount() + DruidDataSource.getActiveCount()

·最大连接数：对应 DruidDataSource.getMaxActive()

·活跃连接数：对应 DruidDataSource.getActiveCount()

·空闲连接数：对应 DruidDataSource.getPoolingCount()

·等待连接数：对应 DruidDataSource.getWaitThreadCount()

注意：说明：

注意：对于其他连接池，APM 会按照类似的方式采集连接数指标。由于实现机制的差异，部分连接池可能不会上报等待连接数指标。

21、方法执行分析

方法执行分析通过插桩技术，对指定方法体中不同环节的执行耗时进行逐行统计，帮助你精确定位某个方法内部的性能瓶颈，即到底慢在哪一行代码、哪一个子调用。

22、创建采集任务

1. 单击创建采集任务，在弹窗中填写以下信息：

2. 填写完成后单击确认即开始采集。

23、分析结果

采集完成后，页面展示该方法的逐行执行耗时分析：

结果列表中，入口方法（如 OrderService.generateOrderInfo）以最长的蓝色条显示总耗时，其下逐行列出子调用及其对应的行号与时间轴，方便你直接定位耗时最长的代码行。

24、GC 日志分析

GC 日志分析功能基于 JVM 输出的 GC Log 排查出有可能影响应用性能的潜在风险。

25、操作前提

在使用此功能前，先确保 JVM 已经配置了打印 GC 日志相关的启动参数。

26、打印 GC 日志相关的启动参数

·Java 8

·启动参数示例如下：-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:gc.log -XX:+UseGCLogFileRotation -XX:GCLogFileSize=20M -XX:NumberOfGCLogFiles=5

·必填参数：-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc

·Java 9 及以上版本

·启动参数示例如下：-Xlog:gc*:file=gc_%p_%t.log:time,pid:filecount=5,filesize=20M

·或者直接指定 GC 日志绝对路径：-Xlog:gc*:file=/path/to/gc.log:time,pid:filecount=5,filesize=20M

注意：说明：

注意：其中 file 为必填参数，用于指定 GC 日志文件路径。 更多详细参数设置，请参考 Java 产品文档。

27、创建采集任务

1. 单击创建采集任务，在弹出对话框中选择数据时长，数据时长代表从 GC 日志中向前回溯的时间跨度，然后单击确认。

2. 分析总耗时为数秒至5分钟左右，取决于当前选择数据时长内所包含的 GC 日志内容大小，应用性能监控最多可以分析100MB 的 GC 日志数据，超出部分将被截断。

28、分析报告

分析报告中包含三部分内容：

·JVM 信息：目前仅支持在 JDK 8中展示，记录 JVM 版本、启动参数、系统属性等信息。

·GC 总览（Summary）：在选定时间段有 GC 行为时会展示。需要重点关注日志起始时间、GC 事件总数、GC 吞吐量等信息。GC 吞吐量是衡量 Java 垃圾回收器性能的重要指标，可以尝试不同的垃圾回收器，或者调整垃圾回收器的相关参数，以获取更低的 GC 次数以及更高的 GC 吞吐量。

·分析结果（Analysis）：在选定时间段有 GC 行为时会展示。分析结果总结了 GC 方面可能存在的问题，并给出了问题的原因以及和解决建议，是分析报告的核心内容，需要重点关注结果分析中的 error 和 warn 部分。

参考如下分析报告：

29、GC 总览（Summary）

·GC 事件总数（GC Events）：36586次。该数字偏高，可能意味着应用程序创建了大量的短暂对象，这可能会导致频繁的垃圾回收。

·GC 事件类型（Event Types）：该时间内产生了 PAR_NEW、CMS_INITIAL_MARK、CMS_CONCURRENT、CMS_REMARK、CMS_SERIAL_OLD 这几种类型的 GC。

·并行 GC 事件（Parallel Events）：36585次。

·串行 GC 事件（Serial Events）：1次。

·最大堆使用量（Heap Used Max）：7092037 K。

·GC 后最大堆使用量（Heap After GC Max）：6988066 K。这个数字如果接近最大堆使用量（Heap Used Max），可能意味着应用程序的内存使用效率不高，或者存在内存泄漏。

·最大堆分配量（Heap Allocation Max）：8371584 K。

·元空间最大使用量（Metaspace Used Max）：167164 K。

·GC 后元空间最大使用量（Metaspace After GC Max）：167164 K。

·最大元空间分配量（Metaspace Allocation Max）：1204224 K。

·GC 吞吐量（GC Throughput）：96%。这意味着应用程序在96%的时间内在执行实际的业务逻辑，而在4%的时间内在进行垃圾回收。GC 吞吐量是一个衡量 Java 垃圾回收器性能的指标，它表示的是应用程序运行的时间占总运行时间的百分比。

·最大 GC 暂停时间（GC Pause Max）：7.528秒。如果单次 GC 的暂停时间过长，那么可能会影响应用程序的响应时间和延迟。例如，如果应用程序需要在1000毫秒内完成交易，那么任何一次 GC 暂停超过1000毫秒都是不可接受的。优化的方法可能包括使用并发垃圾回收器（如 G1或 CMS），这些垃圾回收器可以在应用程序运行的同时进行垃圾回收，从而减少 GC 暂停时间。

30、分析结果（Analysis）

分析结果（Analysis）总结了 GC 方面可能存在的问题，并给出了问题的原因以及解决建议，需要重点关注结果分析中的 error 和 warn 部分。例如，在如下示例中，明确指出了 CMS_SERIAL_OLD 垃圾回收器是串行运行的，回收大内存的时候可能会需要非常长的时间，建议通过调整 JVM 参数避免使用串行垃圾回收器。你可以基于分析结果对 JVM 进行调优，并通过应用性能监控的实例监控等功能对比调优后的效果。

31、运行时分析

运行时分析包括如下表：