生产环境 10 分钟黄金时间快速排障：CPU 不定时飙高怎么排查？

2023-01-30
浙江
本文字数：1664 字
阅读完需：约 5 分钟

“ 1 分钟发现-5 分钟响应-10 分钟恢复，是定义故障处理的时效性目标。在阿里巴巴内部经过多年的实践，这也早已成为各个业务稳定性、基础设施稳定性以及大促保障的重要牵引指标。对于故障，最难的往往不是排查解决，而是保证上述 1-5-10 时效性。程序摄像头 Trace Profiling 直击排障痛点，期望帮助用户在分钟级以标准化步骤定位全资源种类的故障根因。”

1. 常规排障痛点

当生产环境 CPU 使用率过高时，我们的常规思路是，登录上机器：

排查占用 CPU 的进程
找出实际占用最高 CPU 的线程
用 jstack 获取对应线程的堆栈信息，找出耗 CPU 的代码位置对应修复

此举易行，但是这一套操作下来，很花时间，而且如果 CPU 一会高，一会正常该怎么排查？比如：对象序列化、反序列化是开发的超高频操作，但是很多小伙伴可能不知道，这是很费 CPU 的。尤其在对象很大的时候，在生产环境就容易引起 CPU 飙高，但持续时间又很短，难以捕捉的情况，这种无法稳定复现的该怎么排查？

2.案例说明

我们模拟了上述场景，对一个 6M 大小的对象用不同的序列化框架进行序列化操作，并捕捉了请求 Trace，耗时如下：

Fastjson：285.00ms
Jackson：255.29ms
Gson ：283.08ms
net.sf.json：655.06ms

我们来看下程序摄像头是如何通过标准化排障步骤，实现 10 分钟内快速排查这个因大对象序列化导致 Trace 异常耗时问题的：

3. 程序摄像头 Trace Profiling 标准化步骤排障

3.1 找关键 Trace

通过 Trace 系统，结合时间点，找出相关可能存在问题的关键 Trace，并在程序摄像头系统上找到需要排查的 Trace 的 profile 记录。

3.2 查 Span 信息

选择好 profile 之后，本页面会展示该 Trace 的 span 执行消耗分析，如下图。但是我们只能看到 Span 耗时很长，但不知道时间消耗在哪里。

3.3 分析 Trace 执行线程事件

点击 Span 展开，查看对应的详细信息，通过线程事件详情来分析 CPU 异常原因。

我们可以看到，本次 Trace 的执行主线程花了大部分时间在做 running（即 cpu 逻辑计算）事件，点击 running 事件，可查看堆栈信息。堆栈显示，这是系统在执行 JSON.toJSON 操作，从这里我们可以推断出，本次 Trace 是因为执行了大对象的序列化操作，导致 CPU 耗时异常。

4. 精准还原执行现场，10 分钟黄金时间排障

CPU 问题的关键是找到问题代码堆栈，我们普遍的排查方式是“事后诸葛”：出现问题了，再去打堆栈，费时不说，有些难复现的会比较棘手。而程序摄像头 Trace Profiling 像监控一样，在系统请求执行过程中完整记录了我们需要的高 CPU 耗时堆栈，它通过捕捉一次请求下所有的系统调用事件、整合 metric 数据，精准还原现场。颠覆我们以往的排障思路：不再是从问题现象，反查、排除和推理，而是从问题发生现场过程，快速定位根因。以此实现 10 分钟黄金时间快速排障，降低排障门槛，降低对专家经验的依赖。

更多生产环境常见案例以及相应的 demo 试用环境，大家可前往我们的官网查看体验：

http://kindling.harmonycloud.cn/blogs/use-cases/trace-profiling-menu/introduction-menu/