Linux监控需区分指标本质：load average反映任务压力而非CPU使用率；free memory不等于可用内存，应关注available；iowait高未必磁盘慢，需结合await和%util判断；上下文决定指标含义。
Linux监控指标理解错误，往往源于对底层机制的模糊认知。比如把load average当成CPU使用率，或误以为free memory越小系统越卡——这些都不是绝对成立的。关键在于区分“指标数值”和“实际瓶颈”，并结合上下文（如工作负载类型、内存回收机制、I/O调度策略）综合判断。
Load Average ≠ CPU 使用率
Load average 是单位时间内处于可运行状态（R）或不可中断睡眠状态（D，通常是等待磁盘 I/O）的平均进程数。它反映的是系统整体“任务压力”，不单指 CPU。
- 在高并发 I/O 场景下（如大量数据库写入），即使 CPU idle 很高，load 也可能飙升；
- 多核机器上，load = 4 在 4 核系统中未必异常，但若持续 > 8 就需关注；
-
uptime或top显示的三个值（1/5/15 分钟）是指数衰减平均，不是简单滑动窗口。
Free Memory 并不等于“可用内存”
Linux 会尽可能利用空闲内存做 page cache 和 buffer，提升 I/O 性能。因此 free -h 中的 available 列才更接近真正可立即分配的内存，而 free 列常接近于零属正常现象。
- 关注
available值是否持续低于应用所需； - 若
swap used持续增长 +available接近 0，才说明内存真正紧张； -
cat /proc/meminfo中的MemAvailable是内核估算值，比free更可靠。
iowait 高 ≠ 磁盘慢，可能是进程行为问题
%iowait（top 或 vmstat 中）表示 CPU 等待 I/O 完成的时间占比。但它只在所有 CPU 都空闲且有进程在等 I/O 时才会计入，因此：
- 多线程 CPU 密集型程序阻塞在 I/O 时，iowait 可能很低，但磁盘队列已满；
- 真正反映磁盘压力的是
await（iostat -x）、%util和avgqu-sz； - 频繁的小文件随机读写、无缓存直写（O_DIRECT）、或 ext4 的 journal 模式都可能抬高 iowait，但不一定是硬件瓶颈。
Context Switches 高需分清自愿与非自愿
cs（context switches/sec）过高不一定代表性能差，要结合 in（interrupts/sec）和进程状态看：
- 自愿切换（
sleep,wait）多，说明程序设计合理，主动让出 CPU； - 非自愿切换（被抢占、时间片用完）多，配合高
run queue长度，才提示 CPU 资源争抢； - 可通过
pidstat -w查看各进程的 cswch/s（自愿）和 nvcswch/s（非自愿）。
不复杂但容易忽略：同一指标在不同场景下意义可能完全相反。监控不是看数字高低，而是理解数字背后的资源流转路径。
