这一章在做什么

什么时候翻这一章

• 板子上只有 busybox，没有 sysstat、perfmpstat、pidstat、vmstat 的数都是从 /proc 和 /sys 读出来再相减的，自己读也能算。§4.2.1§4.3.1§4.3.2场景手册 →
• 想在线上跟踪，又怕把服务拖慢先分清你要的是计数、采样还是逐个事件，再按事件率估开销。§4.2.3§4.3.5§4.3.7
• 某个工具或监控面板的数看不懂、或者怀疑它算错了找到它读的是哪个文件、哪个接口，再拿另一个来源交叉核对。§4.3.1§4.6
• 问题昨天下午出现过，现在没了sar 开着的话，历史数据就在 /var/log/sysstat 里。§4.4.2
• 新机器上线前，想把排查工具备齐出事时再装往往来不及，内核配置和帧指针也要提前准备。§4.1.2

第 1 章 §1.7 先介绍过计数器、剖析、跟踪和静态、动态插桩，这一章把它们落到 Linux 的具体接口上。第 6–11 章按资源用这些工具；perf、Ftrace、BPF 三件跟踪器的细节在第 13–15 章。

先用中文过一遍

计数器：内核一直在数，工具只是读两次相减

内核里到处是只增不减的整数：收了多少包、发了多少次磁盘 IO、每个 CPU 在用户态待了多少个 tick。它们本来就在加，你不读也在加，所以开销只在读的那一下（§4.2.1）。常见的做法是成对维护：一个数事件次数，一个累计事件花的时间，两者一除就是平均延迟。

工具拿到的都是「从开机到现在」的累计值，单看没有意义。vmstat 1、mpstat 1 做的事就是：隔一秒读一次，相减，再除以间隔。这也解释了一个老现象：这类工具的第一行常常是开机以来的平均，和后面几行不是一回事（§4.2.1）。在只有 busybox 的板子上，你可以用 cat 和 awk 做同样的减法，下面的第一个实验就是这么做的。

精度要心里有数：默认配置下 CPU 时间按时钟中断的 tick 记账，一个 tick 可能是 4 毫秒，看分钟级的趋势够用，看几毫秒的短任务就粗了（§4.3.1）。内核也提供更细的记账方式，代价是一点额外开销。

采样和跟踪：开销跟着谁走

计数器只告诉你「多少」，说不出「哪段代码」「哪一次慢」。剖析（profiling）是定时拍快照：每秒在每个 CPU 上打断 99 次，记下当时的指令地址或调用栈。打断的频率是你定的，所以开销事先就能估出来，这是它在生产上相对安全的原因（§4.2.2）。

跟踪（tracing）是每个事件都处理：每次磁盘 IO、每次调度、每次系统调用都走一遍插桩代码，记下来或者在内核里汇总。好处是一个都不漏，代价是开销和事件率成正比，事件一突发，开销跟着涨，被跟踪的程序变慢，量出来的时间戳也可能被跟踪器自己拉长（§4.2.3）。书里给的经验值是：今天常见的 4 到 128 核机器上，每秒一万个事件以下几乎感觉不到，十万以上开始能量出来；磁盘事件多在前一档，调度事件常在后一档（§4.3.5）。

事件从哪来：静态和动态，内核和用户态

跟踪器本身不产生事件，它挂在内核提供的事件源上。分两个维度看就清楚了。静态插桩是写代码的人预先埋好的点：内核里叫跟踪点（tracepoint），用户程序里叫 USDT。它们有名字、有固定的参数，相对稳定，作者的说法是「尽力而为的稳定」（§4.3.5）；不开的时候在 x86_64 上只是一条 5 字节的空指令。动态插桩是运行时把指令改掉、临时插进去：内核里叫 kprobes，几乎任何内核函数都能挂；用户态叫 uprobes，任何用户函数都能挂。好处是没有人预先埋点也能看，坏处是挂的是内部函数，换个内核版本或程序版本就可能改名、被内联、参数变了（§4.3.6）。

书里自己的类比是：USDT 之于 uprobes，正如跟踪点之于 kprobes（§4.3.8）。所以选的顺序也一样：有静态的点就用静态的，没有才用动态的兜底。用户态那一列还有一个额外的价钱：uprobes 靠陷入内核实现，每次的代价比内核里的探针高一个量级，USDT 在 Linux 上也是用 uprobes 实现的（§4.3.7、§4.3.8）。

还有两类源不在这四格里。一是硬件计数器（PMC）：处理器里能编程的计数寄存器，只有它能告诉你每周期执行了几条指令、缓存命中率多少。它有两种用法：只计数，开销几乎为零；溢出采样，每 N 次事件打断一次记下现场，用来找是哪段代码（§4.3.9）。二是 ptrace：strace、gdb 用的老接口，每个系统调用都要把目标停下来、切到跟踪器、再切回去，书里说可能慢一百倍以上（§4.3.10）。

方法：按什么顺序查

这一章本身没有给排查顺序，但它把数据源从便宜排到贵，也说清了哪些稳定、哪些会变。本站据此整理出「想看一个数时按什么顺序找来源」，原则是先用现成的计数器，不够再采样，最后才逐个事件跟踪。

1. 内核是不是已经在数了？

   先翻 /proc（进程和全系统）、/sys（设备和 CPU）、/sys/fs/cgroup（容器），网络的看 nstat、ss。读两次相减就是速率，任何时候都能读。§4.2.1§4.3.1§4.3.2

2. 某个工具显示的数，到底是哪个计数器？

   strace -e trace=openat,socket 工具名 看它打开了哪些文件、开了什么套接字；再查 man 5 proc 和内核文档里那个字段的定义。§4.3.1§4.3.4

3. 想知道 CPU 花在哪段代码：采样

   perf record -F 99 -g 这类定时采样，频率定了开销就定了。要看缓存未命中落在哪，用 PMC 的溢出采样，注意 skid。§4.2.2§4.3.9

4. 要每个事件的细节：先找跟踪点，先估事件率

   perf list tracepoint 或 ls /sys/kernel/tracing/events 找有没有现成的跟踪点；先用计数器估一下每秒多少次，十万级的（比如调度事件）要在内核里汇总，别逐条打印。没有跟踪点再用 kprobes，记住它跨内核版本不保证还能用。§4.3.5§4.3.6

5. 应用内部：先 USDT，再 uprobes

   先看程序或库有没有带 USDT 探针（有些要从源码重新编译才打开）；没有才用 uprobes，热路径上的函数每次多付微秒级，算一算再开。strace、gdb 别挂到线上高频路径上。§4.3.7§4.3.8§4.3.10

6. 第一次用的指标，先验一验

   用两种来源交叉核对，或者施加一个已知的负载（比如一个绑在某个核上的死循环），看工具报的是不是你预期的数。§4.6

工具速查

procps（ps、top、vmstat）和 util-linux 一般系统自带；mpstat、pidstat、sar、sadf 在 sysstat 包里；nstat、ss 在 iproute2；strace 单独一个包；perf 在 Debian 上是 linux-perf；bpftrace 和 bpfcc-tools 各一个包。读 /proc、/sys 的计数器、用 mpstat 和 sar 不需要 root；列跟踪点、读 tracefs、bpftrace 和 BCC 都要 root。书 §4.1.2 有一张出事前就该装好的包的清单，值得照着给自己的机器过一遍。

动手：在自己的机器上试

# cpupct.sh [N]：隔 1 秒读两次 /proc/stat，算出 cpuN（不给 N 就是全部 CPU）这一秒的各项百分比
c="cpu${1:-}"
a=$(grep "^$c " /proc/stat); sleep 1; b=$(grep "^$c " /proc/stat)
printf '%s\n%s\n' "$a" "$b" | awk '
  { for (i = 2; i <= 9; i++) v[NR, i] = $i }        # 第 2–9 列：user nice system idle iowait irq softirq steal
  END {
    for (i = 2; i <= 9; i++) { d[i] = v[2, i] - v[1, i]; t += d[i] }
    if (t == 0) t = 1
    printf "%-5s usr %5.1f  sys %5.1f  iowait %5.1f  soft %5.1f  steal %5.1f  idle %5.1f   (共 %d 个 tick)\n",
      $1, 100*d[2]/t, 100*d[4]/t, 100*d[6]/t, 100*d[8]/t, 100*d[9]/t, 100*d[5]/t, t
  }'

# pidpct.sh PID：隔 1 秒读两次 /proc/PID/stat 和 /proc/PID/schedstat
# stat 的第 14、15 个字段是 utime、stime（单位 tick）；进程名里带空格时字段会错位，这里的 sh 没有
p=$1; hz=$(getconf CLK_TCK)
s1=$(cut -d' ' -f14,15 /proc/$p/stat); q1=$(cat /proc/$p/schedstat)
sleep 1
s2=$(cut -d' ' -f14,15 /proc/$p/stat); q2=$(cat /proc/$p/schedstat)
echo "$s1 $q1 $s2 $q2" | awk -v hz=$hz '{
  printf "utime %+d tick  stime %+d tick  ->  usr %.0f%%  sys %.0f%%\n", $6-$1, $7-$2, 100*($6-$1)/hz, 100*($7-$2)/hz
  printf "schedstat: 在 CPU 上 %.0f ms，排队等 CPU %.0f ms，上 CPU %d 次\n", ($8-$3)/1e6, ($9-$4)/1e6, $10-$5 }'

# 计数单位：USER_HZ
$ getconf CLK_TCK
# 一个死循环绑在 3 号核上，8 秒后自动退出；同时用脚本和 mpstat 各量一秒
$ taskset -c 3 timeout 8 sh -c 'while :; do :; done' &
$ sh cpupct.sh 3 & mpstat -P 3 1 1
# 两个死循环挤在 5 号核上，取其中一个的 PID，脚本和 pidstat 各量一秒
$ taskset -c 5 timeout 8 sh -c 'while :; do :; done' &
$ taskset -c 5 timeout 8 sh -c 'while :; do :; done' &
$ P=$(pgrep -n -f 'sh -c while')
$ sh pidpct.sh $P & pidstat -u -p $P 1 1

CLK_TCK:   100

cpupct.sh: cpu3  usr 100.0  sys 0.0  idle 0.0  (共 101 个 tick)
mpstat:    CPU   %usr    %sys   %idle
             3  100.00    0.00    0.00

pidpct.sh: utime +50 tick  stime +0 tick  ->  usr 50%
           schedstat: 在 CPU 上 504 ms，排队等 CPU 500 ms，上 CPU 125 次
pidstat:   %usr  %system  %wait  Command
          50.00     0.00  50.00  sh

# mpstat、pidstat 各打开了哪些 /proc、/sys 文件（只统计路径）
$ strace -e trace=openat -o mp.log mpstat 1 1 > /dev/null
$ grep -o '"/\(proc\|sys\)/[^"]*' mp.log | tr -d '"' | sort | uniq -c
$ strace -e trace=openat -o pid.log pidstat -u -p $$ 1 1 > /dev/null
$ grep -o '"/\(proc\|sys\)/[^"]*' pid.log | tr -d '"' | sort | uniq -c
# ip 不读文件，开的是 netlink 套接字
$ strace -e trace=socket ip -s link show eth0 2>&1 > /dev/null | grep NETLINK
# 同一个程序：单独跑、被 strace 全程跟着、只让内核在 openat 上停
$ time dd if=/dev/zero of=/dev/null bs=1 count=20000
$ time strace -o /dev/null dd if=/dev/zero of=/dev/null bs=1 count=20000
$ time strace -e trace=openat -o /dev/null dd if=/dev/zero of=/dev/null bs=1 count=20000
$ time strace --seccomp-bpf -f -e trace=openat -o /dev/null dd if=/dev/zero of=/dev/null bs=1 count=20000

mpstat:   2 /proc/stat
          2 /proc/uptime
          1 /proc/interrupts
          1 /proc/softirqs
         16 /sys/devices/system/cpu/cpuN
pidstat:  2 /proc/PID/stat
          2 /proc/PID/schedstat
          2 /proc/PID/status
ip:       socket(AF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_ROUTE) = 3

real 0m0.015s   dd 单独跑
real 0m5.315s   strace 全部系统调用（另一次 2.1 s）
real 0m3.209s   strace -e trace=openat
real 0m0.027s   strace --seccomp-bpf -f -e trace=openat

成书之后

分节地图

这一章分四块：工具的分类（§4.1–4.2）、数据源（§4.3）、sar（§4.4）、跟踪器简介和对指标的怀疑（§4.5–4.6）。先读的是三类工具的开销、/proc 和 /sys、出事前该装什么、以及怎么怀疑一个数；跟踪点、kprobes 这几节要用 BPF 或 perf 时再回来查。

1. Operating systems have historically provided…约 300 词开篇过去靠推断，现在有动态跟踪；学习目标，扫一眼当目录。
2. Tool Coverage约 100 词工具覆盖面一张按内核组件标注工具的图的引子。
3. Static Performance Tools约 100 词静态性能工具系统不在负载下时查配置的工具，配合第 2 章的静态调优。
4. Crisis Tools约 300 词救急工具出事前就该装好的包，还有内核配置和栈回溯的准备。
5. Tool Types约 100 词工具类型全系统还是单进程，计数还是事件，两个维度分类。
6. Fixed Counters约 400 词固定计数器成对的累计计数器怎么换算成速率和平均延迟，为什么近乎免费。
7. Profiling约 300 词剖析定时采样和按硬件事件采样，开销为什么能预估。
8. Tracing约 400 词跟踪每个事件都处理的代价；调试器为什么不适合生产。
9. Monitoring约 600 词监控sar、SNMP 和代理式监控；监控产品的系统指标和命令行工具同源。
10. Observability Sources约 200 词观测数据源一张数据源总表的引子，后面逐个讲。
11. /proc约 800 词/proc进程和全系统的文件各有哪些、谁在读；CPU 统计的精度。
12. /sys约 200 词/sys按设备组织的统计和可写的控制文件。
13. Delay Accounting约 100 词延迟统计每个任务四种等待的时间；新内核要手动打开，见成书之后。
14. netlink约 200 词netlink二进制的套接字接口，比解析 /proc 省；ss、ip 用它。
15. Tracepoints约 1100 词跟踪点参数和格式串、两种打开方式、开销的经验值。写跟踪前读开销那段。
16. kprobes约 600 词kprobes任意内核函数的动态探针，和跟踪点的取舍，返回探针怎么计时。
17. uprobes约 400 词uprobes用户函数的动态探针，为什么比 kprobes 贵得多。
18. USDT约 400 词用户态静态跟踪程序自带的稳定探针，常要编译时打开；JIT 语言的动态 USDT。
19. Hardware Counters (PMCs)约 800 词硬件计数器计数和溢出采样、寄存器数量有限、skid 和精确事件、云上能不能用。
20. Other Observability Sources约 700 词其他数据源MSR、ptrace、抓包、进程记账、软件事件，以及 Solaris 的 Kstat 对照。
21. sar约 100 词sar作者为什么在 BPF 时代仍然看重 sar。
22. sar(1) Coverage约 100 词sar 的覆盖面各个选项对应哪些子系统，连风扇和温度都有。
23. sar(1) Monitoring约 400 词用 sar 留存数据打开收集、调频率、收全部统计组、导出成 JSON 和 CSV。
24. sar(1) Live约 100 词实时模式带间隔参数时实时输出，不需要开收集。
25. sar(1) Documentation约 100 词sar 的文档手册页给每个指标标了对应的 SNMP 名字。
26. Tracing Tools约 300 词跟踪工具perf、Ftrace、BPF、SystemTap、LTTng 各擅长什么，作者自己怎么分工。
27. Observing Observability约 400 词观测观测工具本身工具、文档、采集脚本都会错；怎么交叉验证，以及缺失的指标。
28. Exercises约 100 词习题习题；本页的诊断题和两个实验可以代替。

词与短语

只收先读和用到再查两档的节。斜体那一行是原句里连续的几个词，在电子书里搜它就能找到那一句。

§0 开篇

§4.1.2 Crisis Tools

§4.2 Tool Types

§4.2.1 Fixed Counters

§4.2.2 Profiling

§4.2.3 Tracing

§4.2.4 Monitoring

§4.3.1 /proc

§4.3.2 /sys

§4.3.3 Delay Accounting

§4.3.5 Tracepoints

§4.3.6 kprobes

§4.3.7 uprobes

§4.3.8 USDT

§4.3.9 Hardware Counters (PMCs)

§4.3.10 Other Observability Sources

§4.4 sar

§4.4.2 sar(1) Monitoring

§4.5 Tracing Tools

§4.6 Observing Observability

诊断题：换成你来查

场景和输出都是本站编的。先自己判断，再点选项看解释。

  PID  %CPU  COMMAND
  612  12.0  top
  455   6.1  camd

vmstat:   r      cs   us  sy
          6  183402   41   9

pidstat:  kB_wr/s  iodelay  Command
           5120.0        0  logd
sysctl:   kernel.task_delayacct = 0

  <not supported>   cycles
  <not supported>   instructions
     60,012.4 msec    task-clock

值得停下来的句子

event rates of less than 10,000 per second cost negligible overhead, and only over 100,000 does the overhead begin to become measurable.— §4.3.5。本站译：每秒一万个事件以下，开销可以忽略；超过十万，开销才开始量得出来。

这是一条能直接拿来算的经验值。要开跟踪之前，先用便宜的计数器估一估事件率：磁盘 IO 在 /proc/diskstats 或 iostat 里，上下文切换在 vmstat 的 cs 列，网络包在 /proc/net/dev。落在万次以下，放心开；到了十万级，就把逐条输出换成内核里的直方图，并缩短开着的时间。作者说这是自己在 4 到 128 核的机器上的体会。本站的看法：核少、主频低的 ARM 板上，门槛要再放低一些。

Regard with a healthy skepticism any statistics that are new to you, questioning what they really mean and whether they are really correct.— §4.6。本站译：对任何你没见过的统计数据，都要保持适度的怀疑：问一问它到底是什么意思，是不是真的对。

这一章前面讲的都是「数从哪来」，这一句告诉你知道来源的用处：能验证。第一次在仪表盘上看到一个指标，先找到它读的文件，再用一个已知的负载去对它；本页第一个实验就是这么做的。延迟统计默认关掉、iodelay 恒为 0 这种事，不去验证就会被当成「没有 IO 等待」。

带走的几条

一句话：先用内核一直在数的计数器，不够再采样，最后才逐个事件跟踪；每个数都要知道从哪来、要付多少代价。