先还原一个现场告警群弹出“CPU 使用率超过 85%”登录服务器一看曲线像心电图一样上下跳但业务流量没有明显变化也没有发布变更。top 翻了半天前五的进程换了一茬又一茬vmstat 扫了几轮runqueue 偶尔冒到 4好不容易瞅准一次飙高perf record 还没采完峰值已经过去了。这种“CPU 莫名抖动”最容易把一个团队从下午耗到后半夜。后来我基本都让 SysOM Agent 先上场。SysOM 是阿里开源的系统运维诊断平台Agent 是部署在每个节点上的采集与诊断组件它带着一系列 SysAK 诊断工具核心依赖 eBPF 探针观测的是调度延迟、runqueue 延迟、softirq 耗时这类常规 top/sar 根本看不到的内核级指标。配合 Agent 上报到控制台的曲线大多数 CPU 抖动问题能压缩到三分钟内出方向。这篇文章会把 CPU 抖动的分类、排查工具选型、SysOM Agent 的观测原理以及真实场景下的定位过程都写透适合正在被 CPU 抖动折磨的运维、SRE以及想了解 eBPF 观测价值的后端开发。不保证每个 case 都能三分钟闭环但常规问题按这套逻辑基本能避免“越查越迷糊”。1. CPU 抖动不是玄学先分清它在抖什么CPU 抖动给人的第一感觉是“没有原因”但工作做得越久越会明白它只是原因藏在了你还没看见的那一层。要快速定位第一件事不是急着开工具而是先观察抖动曲线的形状。曲线本身就是最好的过滤器它会在你动手之前先把问题范围砍掉一大半。1.1 三种最常撞上的抖动模式按我自己的经验90% 以上的“莫名抖动”可以归成三种形态。周期型抖动尖峰以固定时间间隔出现比如每到整点和半点 CPU 从 5% 冲到 70%持续两三分钟又跌回去。这类问题大多来自 cron 定时任务、监控采数、日志轮转、数据同步。它好查也坑人——好查在于间隔固定守株待兔即可坑人在于 cron 任务一旦多起来你得一个个确认到底是谁在那个时间点动了手。随机型抖动时间点完全没有规律可能一天来几次也可能突然连续抖几分钟就消失。这种抖动往往和外部流量、邻居干扰、调度器异常、瞬时资源竞争有关。它最考验工具因为等你去抓现场时现场可能已经没了只能靠带上下文的观测数据来复盘。锯齿型抖动CPU 曲线像锯齿一样反复爬升再下降幅度不大但持续不停。常见于内存逐渐增长导致 GC 频发或连接数慢慢逼近上限触发回收或者是某条链路的流量在缓慢爬坡后又被限流压回来。三种形态特征和对应的第一反应我整理成了一张表方便拿到问题先对号入座抖动类型曲线特征最可能的根因方向第一优先观测点周期型固定间隔高峰cron、日志轮转、定时同步进程 CPU TOP、crontab随机型无规律短时尖峰突发流量、中断、资源争抢整机 vs 单核、softirq锯齿型持续爬升-回落内存膨胀、连接堆积、限流内存曲线、调度延迟1.2 抖动的三个抽屉有活、隐形占用、调度阻塞分完形态再往下一层拆。CPU 抖动的成因永远逃不过三个抽屉排查的本质就是找到这次抖动掉进了哪个抽屉。第一个抽屉是“真的有活要干”。某个进程在某个时刻突然开始大量计算线程数暴涨负载瞬间变高。这类问题进程列表上一目了然SysOM Agent 的进程排行能把它们立刻拎出来。第二个抽屉是“隐形占用”。CPU 时间被中断、软中断、steal time虚拟化下被宿主机抢占的时间吃掉但这些不会体现在进程 CPU 占用里。很多抖动之所以查不到头绪就是因为运维只盯着进程列表忘了看 CPU 时间里的人——但你又不能说 CPU 没事因为%si、%st明明在涨。第三个抽屉是“调度不健康”。CPU 本身不忙load 也不高但任务在可运行队列里排了很久才轮到执行。典型信号是 runqueue 延迟和调度延迟升高进程本身的 CPU 占用可能只有个位数业务却卡到不行。三个抽屉常常组合出现。最迷惑人的“反常识”情况是进程 CPU 不高、整机 CPU 也不高但调度延迟高得离谱。遇到这种情况基本可以确定问题出在锁等待、优先级压制或者 CPU 亲和性配置上而不是单纯的计算量增长。2. 传统排查工具为什么在“莫名抖动”面前显得弱聊到这里很多人的第一反应是top、vmstat、sar 不也能看吗不能否认它们在常规排查里的价值但当 CPU “莫名抖动”时经典三板斧有明显的力不从心。top 的问题在于瞬时且无上下文。默认 3 秒刷新一次看到的是某个瞬间的快照。抖动如果只持续几十秒你可能正好错过。更重要的是它只能告诉你哪个进程在用 CPU不能告诉你这个进程在 CPU 上是“真的有计算量”还是在自旋等待一把锁。要回答后者你得额外抓调用栈而抓调用栈又必须在抖动发生的瞬间执行时间窗口往往早就过了。sar 的问题在于聚合粒度太粗。默认 10 分钟一次除非提前配置成 1 分钟否则根本捕捉不到秒级抖动。就算配置对了sar 也只能给出整机或单核的聚合使用率无法解释“为什么抖”——它能看到 CPU 高了但看不到是谁引起的、排队排了多久。vmstat 的问题在于解读门槛太高。r 列高代表有任务在排队但你不知道谁在排、排了多久、优先级如何。只看 r 列很多时候只能确认“确实有问题”离根因还很远。还有一个工程化的问题是容器环境断层。节点监控看到的 CPU 使用率和容器/命名空间视角的 CPU 使用率经常对不上。top 里看到的是进程本身但在云原生环境里CPU 调度成本、宿主竞争、Pod 间抢占这些因素并不是简单地加几条docker stats曲线就能归因清楚的。所以面对“莫名抖动”传统工具的核心瓶颈不在于“看不到数字”而在于“数字里没有事件上下文”。你看到 CPU 涨了但不知道谁引起的你看到 runqueue 排队但不知道排的是谁、排了多久。这恰恰是 eBPF 观测工具的切入点。3. SysOM Agent 的观测原理eBPF 探针实际测的是“时间”SysOM Agent 给我的最大感受是它不只是在看“CPU 用了多少”而是在测“任务到底等了多久、CPU 被谁占掉”。这个视角差异就是大部分抖动问题能快速定位的原因。3.1 调度延迟与 runqueue 延迟CPU“忙乱”的直接证据runqueue 延迟也叫运行队列延迟指的是任务已经进入可运行队列、但还没真正被调度上 CPU 执行的那段时间。它衡量的是“排队”。调度延迟sched latency更严格从任务被唤醒那一刻开始计时直到它第一次真正获得 CPU。这两个指标放在一起能回答一个核心问题一个任务明明可以运行却等了多久用生活里的事打比方CPU 使用率只告诉你咖啡店开了几个柜台、柜台忙不忙runqueue 延迟却告诉你顾客排队排了多久。很多时候柜台看着不算忙因为都在等一杯慢咖啡但队伍却很长——CPU 调度里的“慢咖啡”就是锁等待、长时间临界区、优先级翻转。SysOM Agent 基于 eBPF 探针实现这些观测比如把探针挂到内核调度路径上在任务入队和出队时各记一笔时间戳最后汇总成延迟分布。这些数字在 top/sar 里是看不到的但有没有它CPU 抖动是否由“排队”导致判断起来完全是两种效率。3.2 softirq 与 steal time“看不见”的 CPU 占用如果说 runqueue 延迟解决的是“排队”问题那 softirq 和 steal time 解决的就是“CPU 被谁偷偷占掉”的问题。softirq软中断在 CPU 使用率里通常对应%si列。网络收包、定时器、块设备这类事件都会在软中断阶段消耗 CPU但不会体现在任何进程的 CPU 占用里。经典坑是网卡只有一个队列或者 RSS 映射不均导致某个 CPU 核的 NET_RX 软中断特别高。整机 CPU 看着不高但某个 vCPU 直接打满业务请求还是变慢。steal time 是虚拟化场景里的特殊存在。物理机把 CPU 时间片分给多个虚拟机当同宿主机上的邻居负载升高你的 vCPU 实际拿到的执行时间变少这部分少掉的时间会在系统统计里显示为 steal。你会遇到一种莫名的现象业务进程 CPU 不高、系统 CPU 也不高但整机曲线还是在抖——十有八九就是 steal time 在作祟。SysOM Agent 会把 user/system/softirq/steal 拆分展示第一时间就能看出是不是隐形占用。3.3 SysOM Agent 怎么做到“不添乱”讲到 eBPF总有朋友担心在内核里挂探针会不会反而引入问题SysOM 这类成熟工具的通用做法是eBPF 程序必须经过内核验证器校验后才允许运行它只能读取特定事件和数据结构不会改写内核逻辑也不会注入业务代码路径。可以把它理解为在内核里放了一台定点录像机而不是给生产逻辑打补丁。部署上Agent 通常需要 root 或相应 capability 权限才能加载探针。我自己的习惯是日常基础监控只开轻量资源指标真遇到疑难现场再临时打开深层次诊断项排查完随手关掉避免长期占用额外开销。SysOM 控制台里一般也支持按需开启诊断项这是它的一个明显优势——你不用为了一个偶发问题永远开着所有探针。另外SysOM 控制台里的指标通常不会一股脑全铺出来而是按“全局概览—CPU 详情—诊断工具”组织。全局概览给总曲线和进程 TOPCPU 详情里能看到 user/system/softirq/steal 的时间构成再往下才到 sysak 这类带调用栈、延迟分布的命令行工具。这个分层设计本身也暗合了后面的定位思路先看轮廓再看构成最后下钻细节。4. 3 分钟定位链路像剥洋葱一样收敛嫌疑标题里的“3 分钟”不是玄学而是一套固定流程画边界、集中嫌疑、交叉验证。三个步骤各一分钟这也是我处理 CPU 抖动问题时的标准动作。4.1 第 1 分钟把抖动边界画出来第一分钟不查进程先看曲线。打开 SysOM Agent 上报到控制台的节点概览找到告警窗口对应的时间段观察三件事。第一抖动窗口有多长是持续几秒的尖峰还是持续几分钟的高位这能区分“瞬发事件”和“持续竞争”。第二有没有周期把曲线拉宽到 1 小时或 24 小时如果尖峰每隔固定时间出现一次直接跳进周期型分支里去找如果完全无规律准备走随机型分支。第三是整机在抖还是单核在抖绝对不要忽略这个维度。整机所有核一起抖多半是有大计算任务或整体资源受限只有某一个核在抖大概率是中断亲和性不均、线程绑定单核、或者软中断集中在一个核心上。这三件事画完嫌疑范围已经砍掉一大半。此时如果发现曲线在 30 分钟窗口内稳定复现通常不需要做深层次诊断直接去查对应时间点的日志和 cron 列表就能有结果。4.2 第 2 分钟把嫌疑进程集中到五个以内边界画好之后进入第二分钟查看 Agent 统计的进程/线程维度数据。按 CPU 占用排序找到当前抖动窗口的 Top5 进程。注意这里是“窗口内 Top5”而不是“当前瞬时 Top5”否则很容易在抖动未发生时看到一组完全无关的进程列表。如果是在控制台操作一般就是进 CPU 详情页切到进程占用排行再叠加容器维度过滤。紧接着看 CPU 时间构成。把用户态、内核态、软中断、steal time 拆开看——如果si或者st占比突出直接跳去检查 softirq 和虚拟化竞争如果sys很高重点查系统调用和内核路径如果us很高再锁应用侧调用栈。最后看调度延迟。此处最需要关注的是“反直觉项”一个进程 CPU 使用率排名并不靠前但它的 runqueue 延迟或调度延迟明显异常。这说明它很可能不是自己吃饱了而是被锁等待、优先级压制或者 CPU 亲和性配置给卡住了。这类进程往往才是造成业务卡顿、但看起来像是 CPU“莫名抖动”的真凶。4.3 第 3 分钟交叉验证并输出“元凶档案”第三分钟做的事是拿前两分钟形成的假设去做交叉验证。先查变更最近有没有发布、配置变更、cron 调整、内核参数修改。很多抖动问题都不是新出现的而是某个变更改变了资源分布比如一个新加的监控任务和已有定时任务撞了车。再看内核事件用/proc/softirqs确认是哪种软中断在增长用/proc/schedstat看 runqueue 统计如果怀疑虚拟化再用vmstat的 st 列二次复核。Agent 给出的曲线是“画像”这些底层文件是“证据”两者能对上定位就是铁案。最后输出一份“元凶档案”——症状、证据、处置动作三行就够。例如症状 每 30 分钟 CPU 尖峰证据 进程 Top1 为日志归档脚本 crontab 中两个任务重合处置 错峰运行。把档案丢进工单后续回溯和复盘都能直接复用不用再重新查一遍。5. 三次真实抖动事故复盘从“抖动曲线”到“处置动作”光讲方法不落地容易变成纸上谈兵。这里复盘三起我实际碰过的“CPU 莫名抖动”事故它们的共性是传统 top/sar 都给过“是 CPU 高了”的结论但根因差异巨大都不是“再加几台机器就完事”的类型。5.1 周期型cron 任务挤压导致半小时一次高峰当时线上某服务节点CPU 每 30 分钟就会毫无征兆地冲到 70% 附近持续约 2 分钟然后跌回 5%。因为服务本身流量很平稳告警天天刷但业务也没受损开发团队一开始以为是外部请求打进来看了半天流量图毫无对应。SysOM Agent 一上来就露了底CPU 曲线是整齐的周期型尖峰不是随机波动。第二分钟查进程排行窗口内 CPU 最高的任务是一个日志归档相关的脚本而不是业务进程。到节点上核查 crontab 才发现同一时刻叠了两个作业日志清理和数据跨机同步。两者在同一分钟触发CPU 自然被瞬间拉满。处置很简单把其中一个任务错开 15 分钟再给日志清理脚本加个 CPU 配额约束。此后曲线恢复平稳。这个 case 的教训是看到周期型尖峰时别先去查业务流量先问一句“这个节点上到底定了哪些定时任务”。5.2 中断型一个网卡队列打满一个核另一次是某个网关集群业务侧反馈响应偶尔变慢但没有规律。看整机 CPU 只有 20%~30%完全不像有压力。我在 SysOM Agent 的 CPU 时间构成里发现了一个反常点虽然整机空闲但软中断si占比在某段时间里高达 40%而且集中在某一个 CPU 核上那个核的使用率已经接近 100%。顺着这条线索查/proc/softirqsNET_RX 的计数在那个核上持续暴涨其他核几乎没怎么参与。再检查网卡队列配置发现该网卡虽然开了多队列但中断亲和性设置有问题irqbalance也没有正常接管导致全部收包流量压在一个核心上。处置是重新启用 irqbalance把网卡队列逐条绑定到不同 CPU 核上抖动随即消失。这个 case 的典型启发整机 CPU 不高不等于没有单核瓶颈凡是随机抖动又伴随业务卡顿的第一优先去看单核维度而不是整机维度。5.3 虚拟化折叠型steal time 伪装下的“高占用”最后一个 case 来自一个跑在虚拟机里的应用服务。接口延迟分布偶尔会出现长尾CPU 使用率曲线像锯齿一样在 10% 到 30% 之间来回摆。开发自查了很多轮代码没有异常 GC数据库也没有慢查询于是怀疑是资源配额不够。SysOM Agent 把 CPU 构成拆分之后答案非常直接进程 user CPU 很低system CPU 也很低但 steal 时间长时间占据 20% 以上。这把问题从“应用层”直接拉到了“宿主机层”——vCPU 的实际执行时间被宿主机上其他虚拟机抢走了。联系宿主机才发现那台物理机上的虚拟机密度偏高邻居出现负载高峰时这个实例的 CPU 时间片就会被挤压。处置方向从“继续查代码”变成了“调整 CPU 请求配额 必要时迁移实例”。这个 case 想强调一点在云或虚拟化环境里看到 CPU 莫名抖动先看一眼 steal 列它经常是伪装成“应用变慢”的外部因素。6. 本地实操把 SysOM Agent 跑起来并演练一遍定位讲完真实案例最后给一套能在本地复现的实操流程。原则是尽量简化让没有生产环境的同学也能体会到 eBPF 观测的威力。6.1 部署前置条件与最小安装软件方面SysOM Agent 需要 Linux 环境内核建议在 4.18 以上以支持 eBPF如果走 CO-RE 模式则 5.4 以上会更舒适。硬件要求不高单核 1GB 内存足够跑基础观测但深层次探针会占一点 CPU 开销不建议在极小的机器上全量开启。安装并不复杂从官方仓库或发行版包拿到 agent 的 deb/rpm 包装上后修改配置写入 sysom server 的地址和节点 token然后启动服务。启动成功后Agent 会周期性采集指标并交给 Server 端归档展示。本地如果想快速验证探针能力可以直接使用随包或配套的 SysAK 命令行工具# 查看系统实时负载曲线 sudo sysak loadmonitor # 查看当前 softirq 分布 sudo sysak softirq # 观察调度延迟分布 sudo sysak runlatency命令的具体参数在不同版本间可能略有差异以官方文档为准。整体属于“拿到就能跑”的类型不需要额外写代码交互体验很像给你递了一台观测显微镜。6.2 制造一次可控抖动用 SysOM 视角完成定位安装完成后可以在测试机上有意识地制造一次 CPU 抖动然后完整地走一遍定位流程。比如调度 stress-ng 跑满一个指定的 CPU 核模拟“某个进程突然开始大量计算”的场景# 让 CPU2 上的单线程压力任务跑 3 分钟模拟计算峰值 taskset -c 2 stress-ng --cpu 1 --timeout 180s此时打开控制台的 CPU 曲线会看到对应核的使用率被拉高进程排行里 stress-ng 会出现在 Top 位置进一步抓它的调用栈或看 CPU 时间构成确认是纯用户态计算。整个过程几分钟内就能完成你会直观感受到“曲线 → 进程 → 根因”的下钻链路。再想验证 softirq 场景可以换一种玩法在另一台机器上用 ping 或小流量工具持续打网卡包观察/proc/softirqs里 NET_RX 的变化。虽然单机很难复现生产环境那种单核打满但至少能理解为什么 Agent 会把 irq/softirq 单列出来——因为它们确实会影响 CPU 曲线却不出现在进程列表里。6.3 三个容易踩到的坑实操和上线前有几点建议都是我自己踩过或见别人踩过的。第一个坑是内核版本不够就盲目开探针。eBPF 探针对内核版本有硬要求太老的内核可能编译通过但加载时报错或者明明采集了数据却映射不到事件。上线前先确认内核版本拿测试机验证能跑通再放到业务节点。第二个坑是探针开太多反而本末倒置。诊断是有成本的观测虽然工具尽量把开销压低但长期高并发场景下大量探针仍然会影响调度。正确姿势是日常只保留资源类指标遇到抖动现场再按需开启深度诊断项。第三个坑是控制台曲线默认聚合间隔较长可能抹平短时尖峰。看到曲线“没问题”不代表现场真的没问题需要下钻看原始事件。迟迟找不到抖动时不妨把时间范围缩小、聚合粒度调细再配合 sysak 的命令行看实时输出。最后分享一个我个人用了很久的习惯遇到任何 CPU 抖动第一反应不是去翻进程列表而是先截一张抖动窗口的曲线图存下来。哪怕暂时没定位到具体原因这张图也是后续排查和复盘最可靠的证据。后来很多同事问我“你定位怎么这么快”其实基本功就是这么几张图加三层收敛——画边界、集中嫌疑、交叉验证。SysOM Agent 也好SysAK 也好它们本质上只是帮我把这三步做得更快、更可视化。希望这篇内容能帮你们从 CPU 莫名抖动的泥潭里爬出来下次再遇到先别慌打开观测工具把边界画出来再说。