Linux监控不准主因是指标理解偏差或采集逻辑滞后：CPU百分比在多核下非超载信号，磁盘%util在4.19–4.20内核失真，内存RES含可回收缓存，load average反映进程排队而非CPU占用。
Linux监控指标不准，往往不是工具坏了，而是对指标含义理解有偏差，或采集逻辑与系统变化不匹配。关键在弄清“它到底在算什么”，再针对性修正。
CPU使用率：多核下百分比≠超载
Zabbix的proc.cpu.util默认按单核100%为基准，双核跑满就是200%，24核跑满就是2400%。top显示的是整体利用率（总占用时间 ÷ 总可用时间 × 100%），数值天然不同。误把240%当成异常，可能只是正常用了2.4个核。
- 查进程真实核数占用：用ps -o pid,ppid,pcpu,comm -C nginx看实际CPU时间占比
- 统一对比基准：在Zabbix中改用system.cpu.util[all,avg1]获取整体平均值，更接近top的视觉习惯
- 高并发服务（如Java）需关注线程级：读取/proc/PID/task/TID/stat，避免只看主进程掩盖热点线程
磁盘I/O使用率：内核升级后统计逻辑变了
Linux 4.19–4.20内核修改了/proc/diskstats中IO完成时间的统计方式，导致iostat、sar和各类Agent沿用旧公式计算出的“%util”严重偏高——它已不能反映设备忙闲程度，而更像一个IO请求堆积的信号。
- 验证是否受影响：运行uname -r，若输出为4.19.x或4.20.x，大概率存在该问题
- 临时规避：改用iostat -dx 1中的%await（平均等待毫秒）和r/s、w/s（IOPS）代替%util判断压力
- 长期解决：升级到4.21+或回退至4.18及更早稳定内核，避免依赖过时统计口径
内存使用率：缓存不算“真正占用”
top、ps显示的“RES”或“%MEM”包含大量可随时回收的page cache和buffer，而free命令中的available字段才代表当前可立即分配给新进程的内存。两者差值常达数GB，不是泄漏，是Linux主动利用空闲内存提速IO。
- 判断真实压力：重点看free -h输出的available列，低于总内存10%才需警惕
- 识别缓存成分：cat /proc/meminfo | grep -E "^(Cached|Buffers|SReclaimable)"，这些加起来基本等于top里多出的“占用”
- 共享内存注意：多个进程映射同一段shm，top会重复计入各进程RES，但实际只占一份物理内存
系统负载（Load Average）：不是CPU使用率
load average（如1.23 1.15 1.08）表示单位时间内处于R（运行）或D（不可中断睡眠）状态的进程平均数量，反映的是排队长度，而非CPU正在干多少活。即使CPU idle 90%，若所有进程都在等磁盘，load仍可能飙高。
- 健康参考线：load值持续高于CPU逻辑核心数，说明有资源争抢；但单次峰值不必紧张
- 定位瓶颈：结合iostat -x 1看%util和%await，vmstat 1看b（阻塞进程数）和wa（IO等待），交叉印证
- 区分场景：短时高load可能是批量任务，长时高load且wa高=磁盘瓶颈，sy高=内核态开销大（如频繁上下文切换）
