Linux 运维中指标选择的原则

监控指标不在于多，而在于“精准”

运维中最大的误区，是把所有能采集的指标都塞进监控系统——结果告警泛滥、噪音压过信号。真正影响业务可用性的关键指标其实很窄：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 服务来说就偏高。

实操建议：

• 用 sar -q 1 300（采样 5 分钟）代替单次 uptime，避开瞬时毛刺
• 对 Java 应用，jstat -gc 的 FGCT（Full GC 次数）比堆内存使用率更有预警价值——GC 频繁但堆未满，说明对象生命周期设计有问题
• SSD 场景下，iostat -x 1 中的 svctm 已无意义，重点盯 r_await/w_await 和 aqu-sz（平均队列长度）

避免“指标幻觉”：有些数字天生不可靠

%idle 在超线程 CPU 上可能虚高；free 输出的 used 包含 buff/cache，直接拿它除以总内存算“使用率”会误判；top 默认显示的 CPU 使用率是所有核心加权平均，掩盖单核 100% 卡死的问题。

所以必须交叉验证：

• 怀疑单核瓶颈？用 mpstat -P ALL 1 看每个核心的 %usr
• 不确定内存是否真紧张？cat /proc/meminfo | grep -E "MemAvailable|Cached|SReclaimable"，用 MemAvailable 值为准
• 网络丢包疑云？别只信 ifconfig 的 Errors，跑 ethtool -S eth0 | grep -i "drop|error" 查驱动层真实丢弃计数

最常被忽略的一点：所有指标采集本身有开销。高频轮询 /proc 文件（如每秒多次 pidstat）可能让本就不堪重负的系统雪上加霜——监控频率要和业务 SLA 对齐，不是越密越好。