监控指标不在于多，而在于“精准”
运维中最大的误区，是把所有能采集的指标都塞进监控系统——结果告警泛滥、噪音压过信号。真正影响业务可用性的关键指标其实很窄：CPU 持续高负载 + 进程阻塞、内存 available 低于 500MB、SwapUsed 非零、磁盘 %util >80% 且 await >50ms、网络重传率 retrans >1%。这些才是该立刻响应的信号。
为什么只盯这几个？因为它们直接对应服务中断或响应超时的物理原因。比如 await 高但 %util 低，说明不是磁盘忙，而是队列深或IO路径卡在驱动/控制器层——这时加磁盘没用，得查 smartctl 或 dmesg | grep -i "nvme\|ata"。
必须结合上下文看指标，不能孤立判断
单独一个 %wa（iowait）>20%，不代表磁盘出问题；如果此时 free -h 显示 available 只剩 200MB，那大概率是内存不足触发了内核频繁回收 page cache，进而导致读文件变慢——本质是内存瓶颈，不是IO瓶颈。
常见误判场景：
-
load average高但%idle也高：典型 IO 等待，vmstat 1看b（blocked 进程数）和wa列确认 -
top里%us占 95%，但pidstat -u 1发现全是java进程：不是异常，是应用正常计算；但若同一进程%sys也飙升，就要查是否在频繁read()/write()小包 -
si/so（swap in/out）每秒 >10MB：说明已进入内存严重不足状态，smem -s rss -r | head -5找真实吃内存的进程，而不是只看ps aux --sort=-%mem
阈值必须匹配硬件规模和业务特征
4 核机器的 load average 警戒线不是固定值，而是 nproc × 0.7 ≈ 2.8；8 核服务器跑数据库，%sys 常态 25% 是合理的（大量 buffer 管理、页回收），但对 Web 服务来说就偏高。
