附录不是需要从头背到尾的正文，而是一组“卡住时去哪里找”的入口：附录 A 把 Linux 物理和软件资源映射到 USE 指标；附录 B 把 sar 选项映射到 CPU、内存、磁盘和网络；附录 C 用短例展示 bpftrace 可观测范围；附录 D 只帮助核对少量概念；附录 E 提供技术人物与历史线索。

本章把这些材料压缩成一张诊断导航。它不会复制完整单行命令或练习答案，而是告诉你何时用哪类信息、看到什么信号后如何继续。

1. USE 是覆盖检查，不是自动根因机。 对每项资源依次查使用率、饱和度和错误，目的是避免遗漏。
2. 云端还要把资源控制当作资源。 配额、节流和限速可能先于物理 CPU、内存或设备耗尽。
3. sar 的强项是统一口径与时间趋势。 它能快速横跨 CPU、队列、换页、磁盘和网络，但选项和字段随 sysstat 版本变化。
4. bpftrace 附录是模式索引，不是复制区。 先确认探针、参数和频率，再把示例改成有范围、有时限的本机程序。
5. 速查表必须回到业务结果。 资源异常只有位于请求关键路径并与延时/错误同步，才可能解释用户影响。

USE 导航

使用率是“资源忙了多少”，饱和度是“需求超过即时服务能力后排了多少队/等了多久”，错误是无法完成的事件。不同资源未必有完美的三个指标；缺少现成计数器时，才考虑动态跟踪。

软件资源同样会形成瓶颈：线程数、文件描述符、连接池、锁、队列和 cgroup 配额都有容量上限。它们的“使用率”是占用相对上限，“饱和度”是等待或拒绝，“错误”常以 errno、超时或失败返回出现。物理 CPU 仍有空闲时，CPU quota 的 throttled 时间也可能已经让容器饱和，因此宿主机和租户视角要同时检查。

sar 导航

按问题选择组而不是背参数：CPU 使用与频率、运行队列和上下文切换；内存可用量、页扫描与交换；磁盘吞吐、队列、await；网络吞吐、接口错误、TCP 重传。先看 1 秒粒度趋势，再与应用延时同时间对齐。

1. 列出 CPU、内存、磁盘、网络以及可能的软件配额，逐项填 USE 三列。
2. 用 uptime/vmstat/mpstat/iostat/sar 获取 5–10 个短周期样本，保留时间戳。
3. 找同时出现的信号：例如请求 P99 上升、运行队列增长、CPU idle 降低。
4. 回看 sar 历史数据，判断异常是持续、周期性还是突发；同时核对应用部署和流量事件。
5. 对单一缺口下钻：perf 做计数/剖析，BCC 或 bpftrace 做按进程、栈、延时和错误的聚合。
6. 记录工具版本、单位、CPU/设备范围和缺失指标，避免把速查表中的旧字段当成固定标准。

对资源控制还应单独重复 USE：核对配额使用、节流等待和拒绝错误，而不是只检查物理设备。若只能进入容器，明确哪些宿主指标不可见；把“没有权限观测”记录为证据缺口，不能写成“宿主没有竞争”。

这是一组代表性入口，不是附录的完整清单。命令只读系统统计；bpftrace 的列表命令不附加探针。

~~~bash

# 60 秒检查中的基础视图

uptime

vmstat 1 5

mpstat -P ALL 1 5

iostat -xz 1 5

# sar 按资源查看短时趋势

sar -u 1 5

sar -q 1 5

sar -r 1 5

sar -d 1 5

sar -n DEV,EDEV 1 5

# 只读确认 bpftrace 在本机可用的事件与字段

bpftrace -l 'tracepoint:block:*'

bpftrace -lv 'tracepoint:syscalls:sys_enter_read'

~~~

并非所有发行版都默认采集 sar 历史数据；日志路径、保留周期和字段由 sysstat 配置决定。设备名、网络接口和容器视角也可能不同，先确认你观察的是目标所在的命名空间与宿主资源。

CPU 的 <code>%idle</code> 低说明忙，但是否饱和还要看运行队列和调度延时；Linux 平均负载还包含不可中断任务。内存“free 很少”常是页缓存的正常利用，应结合 available、页扫描、交换和 OOM。磁盘 <code>%util</code> 对并行设备、阵列和虚拟设备没有统一的 100% 含义，await/队列与延时分布更接近用户影响。

网络吞吐未到标称带宽也可能饱和于包率、单流、CPU、队列或策略；错误、drop、重传要按方向和层次定位。sar 的累计/区间值、单位和平均列必须先读表头，不能跨版本或不同采样周期直接拼接。

当速查指标只给出“某资源可疑”，下一步应按业务对象细分，而不是收集更多同类总量：按 PID、cgroup、设备、操作类型、栈或延时桶拆分，直到能提出可验证的修复。

历史数据也需要基线。工作日白天的 70% CPU 可能正常，而凌晨同值可能对应异常任务；一次突发 drop 与持续重传的意义不同。把当前值与同主机过去同时间、同负载正常窗口比较，往往比套用通用阈值更可靠。

• 把 USE 当成固定命令表，运行完却没有形成假设或与业务指标对齐。
• 只看 CPU 使用率，不看队列；只看内存占用，不看回收；只看磁盘忙度，不看延时。
• 把平均负载全部解释成 CPU 需求，忽略不可中断 I/O。
• 直接套用 sar 旧版本的列名和阈值，或混淆区间值与累计值。
• 从附录复制高频 bpftrace 单行命令到生产，未确认探针、范围和开销。
• 把附录中的案例答案和人物列表当作需要背诵的完整课程内容。

1. USE 中“饱和度”与“使用率”有何不同？
2. CPU idle 很低时，还需哪类指标判断是否排队？
3. 为什么 free 内存很少不必然是内存瓶颈？
4. sar 最适合补足实时命令的哪项能力？
5. 从附录找到 bpftrace 示例后，运行前至少核对什么？

检查要点：排队需求与忙碌比例；运行队列/调度延时；页缓存及 available/回收信号；历史和时间趋势；本机探针与字段、事件率、范围、权限和版本。

附录的正确用法是建立路由：USE 保证资源覆盖，sar 建立时间上下文，perf/BPF 完成定向下钻。速查表给的是起点而非阈值真理；每次都要回到当前内核、当前工具、当前工作负载和用户可见结果。