Linux排障工具越学越多但真出事还是不知道先敲哪个，USE方法（Utilization/Saturation/Errors）到底怎么把top、vmstat、iostat串成一条排查主线？

摘要：排障工具的学习曲线与实战决策之间存在一条常被忽视的鸿沟：工具越多，首次命令的选择成本越高。本文以 Brendan Gregg 提出的 USE 方法（Utilization / Saturation / Errors）为分析主线，论证它并非一张“指标清单”，而是一套把资源维度与指标维度正交展开的决策矩阵。文章给出从 top 到 vmstat、iostat、pidstat、sar 的串接路径，逐项拆解利用率、饱和度、错误三类指标在 CPU、内存、磁盘、网络四类资源上的可观测来源与判读阈值，并讨论容器化与 eBPF 时代该方法需要修正的边界条件。全文约 13800 字，参考文献 62 篇。

目录

一、导语：工具爆炸与决策瘫痪

一个运维工程师的终端历史里，往往躺着几十条互不相关的命令：top、htop、vmstat、iostat、mpstat、pidstat、sar、free、ss、netstat、dstat、perf、bpftrace、strace、lsof、slabtop、numastat。每一条都对应过至少一篇“Linux 性能分析必备”的教程，每一条在演示环境里都跑得通。但真正的事故现场不是演示环境：告警在响，业务在掉，时间窗口以分钟计，此时“我知道有二十个工具”和“我知道先敲哪一个”是两种完全不同的能力。

这种落差有一个结构性原因。绝大多数工具教程以“工具”为组织单位，讲的是某个命令有哪些字段、每个字段什么意思；而排障决策以“资源”和“症状”为组织单位，需要的是从症状到资源的映射、从资源到指标的映射、以及从指标到结论的映射。两套组织方式之间没有天然桥梁，于是学习投入无法线性转化为决策速度。本文认为，USE 方法的价值恰恰在于它提供了这座桥：它把“先敲哪个”从经验问题转化为查表问题。

需要提前说明本文的分析主线：USE 方法不是一份指标清单，而是一个“资源 × 指标”的正交矩阵。矩阵的行是系统资源（CPU、内存、磁盘、网络接口、控制器、总线等），列是三类指标（利用率、饱和度、错误）。排障时先定位资源行，再沿列检查，工具只是取数手段。这条主线将贯穿全文，所有章节的展开都服务于它。

二、背景与问题定义：为什么“先敲哪个”是个真问题

2.1 排障的本质是受限搜索

把一次故障排查形式化，可以看作在一个假设空间中的受限搜索：候选假设是“某个资源的某类指标异常”，观测手段是各类工具，观测成本是时间与对生产环境的风险。工程师的目标不是穷尽观测，而是在有限步数内把后验概率最高的假设排到前面。工具越多，单步观测的选择空间越大，若无先验结构，搜索效率反而下降。这与信息检索中的“选择过载”现象同构，本文评述：工具学习的边际收益在缺乏组织框架时会迅速递减，这是“学了很多却不知道先敲哪个”的第一层解释。

第二层解释来自指标的语义混淆。以 CPU 为例，“使用率 90%”与“饱和度 90%”在直觉上相似，在因果上完全不同：前者说明资源被占用，后者说明有任务在排队等待。前者可能完全健康（批处理满载），后者几乎总意味着延迟劣化。若工程师只熟悉“使用率”这一个维度，就会把大量健康的高负载误判为故障，同时漏掉真正的问题——那些使用率不高但队列很长的场景，例如磁盘的 await 飙升而 %util 尚可。

2.2 三类指标的定义边界

为避免后文歧义，先给出本文采用的定义。利用率（Utilization，U）：资源在观测窗口内处于“忙碌”状态的时间比例，或已分配容量占总额的比例。饱和度（Saturation，S）：资源无法立即服务而必须排队的程度，通常表现为队列长度、等待时间或拒绝率。错误（Errors，E）：资源层面发生的可计数错误事件，如网卡 CRC 错误、磁盘介质错误、内存 ECC 纠正、内核丢包计数。三者的关系可以概括为：U 描述“忙不忙”，S 描述“堵不堵”，E 描述“坏没坏”。

2.3 一个被低估的事实：多数工具只覆盖矩阵的一角

把常见工具按“资源 × 指标”落位，会发现覆盖极不均匀。top 主要覆盖 CPU 的 U 与部分 S（load average、运行队列间接反映），对磁盘和网络的 S 几乎无覆盖；vmstat 覆盖 CPU、内存、IO 的 U 与 S，但对 E 基本无覆盖；iostat 覆盖磁盘的 U（%util）、S（aqu-sz、await）与部分 E（通过内核日志间接）。这意味着任何单一工具都不足以完成一次完整的三列检查，串接是必然的，而不是可选的。

这一观察也解释了为什么“只学 top”的人会在 IO 瓶颈前束手无策：top 的 %CPU 高可能来自 iowait 的计入方式差异，而 load average 在 Linux 上把不可中断睡眠（D 状态）也计入，导致 IO 阻塞表现为“CPU 负载高”的假象。关于 load average 的语义，Linux 内核文档与 man 手册均有说明，本文评述：不理解指标定义就使用指标，是把观测误差直接转化为诊断误差。

三、原理：USE 方法的结构与它的隐含假设

3.1 方法的原始表述与本文的重述

USE 方法由 Brendan Gregg 在其性能分析方法学工作中系统提出，核心表述为：对每一项资源，检查利用率、饱和度、错误三类指标。其原始动机是让工程师在信息不全时也能系统性地覆盖检查面，而不是依赖直觉跳跃。本文将其重述为矩阵形式，是为了突出两个此前较少被强调的性质：正交性与可裁剪性。

正交性指行与列相互独立：资源维度回答“查哪里”，指标维度回答“查什么”，二者组合出完整检查面，不重不漏。可裁剪性指矩阵可按场景裁剪：单机排障可裁剪到 CPU、内存、磁盘、网络四行；分布式系统排障则需把“资源”扩展到服务实例、连接池、线程池等逻辑资源。本文评述：正是可裁剪性让 USE 能跨越从内核到应用的层次，而不局限于操作系统课程里的硬件资源。

3.2 隐含假设一：资源是可枚举的

USE 成立的前提是资源能被清晰枚举。物理机上这相对容易：CPU 核、内存、块设备、网卡。但在容器与虚拟化环境中，“资源”的边界变得模糊：容器看到的 CPU 是 cgroup 配额，看到的磁盘是叠加文件系统，看到的网络是 veth 对。此时 U 的分母是谁、S 的队列在哪一层，都需要重新定义。笔者认为，这是 USE 在云原生时代最需要修正的假设，后文第六节将展开。

3.3 隐含假设二：指标可低成本获取

USE 的原始设计面向交互式排障，默认指标获取成本低。这在传统内核计数器上成立：/proc 与 /sys 下的多数计数器读取开销可忽略。但部分饱和度指标并非免费，例如精确的块设备队列深度需要采样，调度延迟需要跟踪点。本文评述：当观测本身开始影响被观测系统时，USE 的“全列检查”应退化为“按症状裁剪的列检查”，这是工程上必须接受的妥协。

3.4 隐含假设三：错误是可计数的

E 列的假设是错误以事件形式可计数。这对硬件错误成立，对软件错误则未必：应用层的超时、重试、降级往往没有统一计数器，需要从日志或指标系统中聚合。因此 E 列在实践中常需要跨层补齐，这也是 USE 与 RED 方法（Rate、Errors、Duration）在应用层衔接的接口。

四、技术路线：把 top、vmstat、iostat 串成主线

4.1 主线设计：三步定资源，三列定指标

本文提出的操作路径分三步。第一步，用低成本全局工具做资源定位，top 或 vmstat 的一行摘要即可完成；第二步，对可疑资源做三列检查，CPU 与内存用 vmstat、pidstat，磁盘用 iostat，网络用 ss 与网卡计数器；第三步，对确认的异常做下钻，用 pidstat、perf、bpftrace 定位到进程与调用栈。三步之间不是并列关系，而是漏斗关系：每一步都在缩小假设空间。

# 第一步：全局资源定位（10 秒内完成）
top -b -n1 | head -20          # CPU 的 U/S 粗看，load average 看 S
vmstat 1 5                     # r 列看 CPU 队列，b 列看阻塞进程，si/so 看换页

# 第二步：按可疑资源做三列检查
iostat -xz 1 5                 # 磁盘 U(%util) / S(aqu-sz, await) / E(日志)
pidstat -u -r -d 1 5           # 进程级 CPU、内存、IO 分解
ss -s                          # 网络连接总量与状态分布

# 第三步：下钻
pidstat -t -p  1          # 线程级分解
perf top -p               # 热点函数
bpftrace -e '...'              # 按需跟踪

这条主线的关键设计在于“先全局后局部”的顺序不可颠倒。先做进程级下钻的常见后果是：在一个并非瓶颈的进程上耗费大量时间，因为缺少全局视图无法判断该进程的异常是否具有系统性。本文评述：排障的时间预算应大致按 1:3:6 分配在三个步骤上，第一步的十秒投入能显著压缩后两步的搜索空间。

4.2 CPU 行：从 load average 到运行队列

CPU 的 U 在 top 中表现为 %CPU 总和，但需注意其统计口径：Linux 的 %CPU 在进程视图下是单核百分比，可超过 100%；在摘要视图下是全部核的平均。S 的主要指标是运行队列长度（vmstat 的 r 列）与 load average。这里有一个常见误判：load average 在 Linux 上包含 D 状态进程，因此 IO 阻塞会推高 load 而不推高 CPU 使用率。判读时应把 load 与 r 列、%CPU 三者对照：load 高而 r 低、%CPU 低，指向 IO 或锁等待而非 CPU 不足。

更精确的 CPU 饱和度指标是调度延迟，即任务从可运行到实际获得 CPU 的时间。该指标无法从 /proc 直接读取，需要 sched 跟踪点或 pressure stall information（PSI）。Linux 4.20 起引入的 PSI 在 /proc/pressure/cpu 中给出 some/full 两行累计值，可换算为阻塞时间占比。笔者认为，PSI 是近年来对 USE 方法最实质的补充，它把“饱和度”从间接推断变成了直接测量，后文第五节给出判读方法。

4.3 内存行：区分容量、回收与换页

内存的 U 是已用容量占比，但“已用”的定义本身有歧义：free 命令的 available 列才是可用估计，buff/cache 可回收。S 的核心指标是换页活动（vmstat 的 si/so）与直接回收（direct reclaim）。E 则是 ECC 错误与 OOM 事件。一个高频误判是把 buff/cache 高当作内存不足，实际上这是内核利用空闲内存做页缓存，属于健康行为。

内存饱和度的现代指标同样是 PSI：/proc/pressure/memory 的 full 行反映所有任务都因内存不足而阻塞的时间占比。与 si/so 相比，PSI 的优势在于它捕捉的是“分配延迟”而非“换页量”，后者在 zswap、zram 等机制下可能失真。本文评述：在启用压缩内存的系统中，仅看 si/so 会低估内存压力，PSI 应作为首选饱和度指标。

4.4 磁盘行：%util 的局限与 aqu-sz 的价值

磁盘的 U 是 iostat 的 %util，其定义为设备在采样期内有 IO 在途的时间比例。这个指标在 SSD 与 NVMe 上解释力下降：并行度高的设备即使 %util 接近 100% 仍可能有富余吞吐。S 的主要指标是 aqu-sz（平均队列长度）与 await（平均等待时间，含排队与服务）。E 需要从内核日志与 SMART 数据获取。判读时应以 await 与 aqu-sz 为主、%util 为辅，因为前两者直接对应延迟。

这里有一个工程上反复出现的陷阱：iostat 的第一次采样值来自系统启动以来的累计平均，不代表当前状态。因此必须使用间隔采样并丢弃第一组数据。本文评述：这一细节在大量教程中被省略，却是“iostat 看起来一切正常”类误判的主要来源之一。

4.5 网络行：从接口计数器到套接字队列

网络的 U 是带宽占链路容量的比例，S 是发送/接收队列与套接字 backlog，E 是接口错误计数（/proc/net/dev 的 errs、drop 列）与协议栈丢包（netstat -s）。与前三行不同，网络没有单一工具覆盖三列，需要组合 ip -s link、ss、nstat。笔者认为，网络行的检查应优先看 E 与 S，因为带宽利用率在现代数据中心中很少成为瓶颈，而队列溢出与重传才是延迟的主要来源。

五、关键数据与案例：三类指标在四类资源上的判读

5.1 判读矩阵总表

下表把四类资源与三类指标交叉，给出每格的推荐观测来源与经验阈值。阈值部分为工程经验值，非普适标准，需结合业务 SLA 校准；来源标注为“工程经验”的条目为本文基于公开文档与常见实践的综合，非单一文献数据。

5.2 案例一：load 高但 CPU 空闲

现象：某服务响应变慢，top 显示 load average 为 32（16 核机器），但 %CPU 总和仅 25%，vmstat 的 r 列为 2、b 列为 28。按 USE 矩阵定位：CPU 行 U 低、S 的间接指标 load 高但直接指标 r 低，说明瓶颈不在 CPU 可运行队列；b 列高指向阻塞。转查磁盘行，iostat 显示某块盘 await 达 180ms、aqu-sz 为 24，而 %util 仅 62%。结论是磁盘队列积压而非磁盘“忙满”。

这个案例的教学价值在于三点：其一，load 必须与 r、b 列联合判读；其二，%util 不是磁盘饱和度的可靠代理，aqu-sz 与 await 更直接；其三，D 状态进程是连接 CPU 行与磁盘行的关键线索。本文评述：如果只学 top，此案例会被误判为 CPU 不足并触发无效扩容，这是工具单一化最典型的代价。

5.3 案例二：内存充足但频繁换页

现象：容器内存 limit 为 4GiB，节点 free 显示 available 充足，但应用 P99 延迟周期性抖动。vmstat 显示 si/so 在抖动期间有非零值，/proc/pressure/memory 的 full 行在同期升至 15% 以上。按矩阵定位：节点级内存 U 正常，但容器级 U 已接近 limit，触发 cgroup 级回收，回收压力表现为 PSI 上升而非节点级换页。

该案例说明 USE 的“资源”必须按作用域分层：节点级与 cgroup 级是两个不同的行。笔者认为，容器环境下的排障应默认采用“双层矩阵”，先查 cgroup 层再查节点层，否则会出现“节点一切正常、业务持续抖动”的经典困境。cgroup v2 的 memory.pressure 与 memory.stat 是这一层的主要数据源。

5.4 案例三：网络错误被应用层掩盖

现象：跨可用区调用偶发超时，应用日志只有“context deadline exceeded”。按矩阵查网络行 E 列：/proc/net/dev 的 drop 计数在超时窗口内增长，nstat 显示 TCPRetransSegs 与 TCPListenOverflows 同步上升。进一步用 ss -lnt 观察，发现 accept 队列在高峰期溢出，根因是应用 accept 速率不足而非网络带宽。

此案例的要点是 E 列的分层：物理层错误、协议栈错误、套接字层错误分属不同计数器，应用层超时只是最终表现。本文评述：把 E 列理解为“从下往上的错误链”比理解为单一指标更有操作价值，因为错误往往在向上传递中被抽象掉，只剩一个笼统的超时。

5.5 数据来源与预处理说明

本文引用的内核计数器语义以 Linux 内核文档与各工具 man 手册为准；PSI 的引入版本与接口格式依据内核文档；load average 的 D 状态计入行为依据内核源码与 man 手册说明。文中阈值类数值为工程经验综合，已在表中标注，不构成对特定硬件的普适结论。涉及性能数据的讨论未使用任何虚构实验，案例为方法论演示性质的场景重构，不指向具体组织。

六、对比与局限：USE 与 RED、四大黄金信号、eBPF 的关系

6.1 与 RED 方法的分工

RED 方法（Rate、Errors、Duration）面向服务而非资源，适合微服务与 API 层。USE 与 RED 不是替代关系而是层次关系：RED 描述“用户感受到什么”，USE 描述“系统内部为什么”。排障路径通常是从 RED 的异常出发，用 USE 定位资源。本文评述：把两者对立起来的讨论多源于混淆了观测层次，实践中二者应组合使用，RED 做告警入口，USE 做根因下钻。

6.2 与四大黄金信号的关系

Google SRE 提出的四大黄金信号（延迟、流量、错误、饱和度）在指标维度上与 USE 有交集，尤其“饱和度”一项几乎直接对应。差异在于黄金信号以服务为中心、以 SLO 为导向，USE 以资源为中心、以检查完整性为导向。笔者认为，黄金信号适合定义“什么是故障”，USE 适合回答“故障在哪”，二者在监控体系中的位置不同，不应互相替代。

6.3 局限一：容器与虚拟化的资源边界

前文已述，容器环境下资源边界模糊。具体表现为：cgroup 的 CPU 配额使 U 的分母变为配额而非物理核；叠加文件系统使磁盘 IO 的归属需要借助 cgroup io.stat；veth 对使网络计数器分散在两端。修正方案是采用分层矩阵，并在每一层明确分母定义。本文评述：这不是 USE 的失效，而是要求把“资源”这一行按作用域展开为多行。

6.4 局限二：eBPF 带来的观测范式变化

eBPF 使内核级跟踪的成本大幅下降，调度延迟、块层延迟分布、TCP 重传原因等此前难以获取的指标变得可得。这对 USE 的影响是双面的：一方面，S 列从间接推断走向直接测量，判读更可靠；另一方面，可观测点爆炸使“检查完整性”不再是约束，约束转为“如何选择有信息量的观测”。笔者认为，eBPF 时代 USE 的角色从“检查清单”转向“假设生成框架”，其价值在于约束观测范围而非穷尽观测。

6.5 局限三：方法不覆盖应用内部逻辑

USE 止步于资源层，对锁竞争、连接池耗尽、GC 停顿等应用内部问题只能间接反映。这类问题需要应用层方法补充，如线程栈分析、GC 日志分析。本文评述：把 USE 当作万能方法是另一种误用，正确的心态是把它作为“从症状到资源”的第一段路径，资源层排除后再进入应用层。

6.6 拓展资源

延伸阅读与实践材料可参考以下公开资源（均在新窗口打开）：Brendan Gregg 的 USE 方法原始说明、Linux 内核 PSI 文档、iostat man 手册、Linux 性能工具图谱、Linux 性能分析公开讲座视频。

七、结论与展望

回到最初的问题：工具越学越多，真出事还是不知道先敲哪个。本文给出的答案是，缺的不是工具知识，而是把工具组织起来的结构。USE 方法提供的正是这个结构：以资源为行、以利用率/饱和度/错误为列，先把检查面铺开，再按症状裁剪。top 负责快速定位资源行，vmstat 负责 CPU 与内存的两列检查，iostat 负责磁盘的两列检查，pidstat 与 eBPF 负责下钻。串接的逻辑不是命令的先后，而是假设空间的逐步收缩。

展望未来，三个方向值得关注。其一，PSI 的普及将使饱和度从推断指标变为一等公民，监控体系应优先采集；其二，eBPF 与 OpenTelemetry 的融合可能让 USE 矩阵自动填充，工程师的角色转向假设生成与验证；其三，容器与 Serverless 的普及要求把矩阵按作用域分层，节点级与实例级指标需分别建模。笔者认为，无论观测技术如何演进，“先定资源、再查三列”的决策顺序不会过时，因为它对应的是排障这一认知活动的基本结构，而非某代工具的偶然形态。

八、主要参考文献