服务器监控装了一堆白搭？这5个常用运维指标你真的关注了吗？

说实话，入行前两年我也犯这个毛病——觉得监控装得越多、仪表盘做得越花哨就越专业，结果天天被几百条甚至上千条没用的报警淹没，最后索性设置了“群消息免打扰+只看严重级别红标”，可真到出事的时候，红标要么姗姗来迟，要么干脆没有，因为阈值设得太松或者完全没设对。踩过无数次这种“监控白搭钱还搭时间”的坑才明白，服务器运维常用的监控指标，你都关注了吗？ 这句话根本不是一句随口问的废话，而是能不能保住饭碗的灵魂拷问，咱们中小团队人少活多，真没必要搞那些花里胡哨的监控项，把这5个基础但调对阈值就能提前预判80%故障的指标盯死就行。

首先提一下大家都懂但90%的人都没正确理解“使用率”和“利用率”区别的基础CPU监控。别再只看top或者htop里的%us（用户态CPU使用率）和%sy（系统态CPU使用率）加起来的总和，这两个数值高不一定是坏事，比如我们的测试环境跑满代码打包流水线的时候，这两个加起来经常在95%以上，反而说明CPU利用率拉满了，没有资源浪费。真正需要敲黑板关注的是%wa（iowait等待时间占比）和top里load average的前两个数字（1分钟和5分钟平均负载），如果%wa持续超过10%，不管CPU总使用率是多少，大概率是磁盘或者IO相关出了问题；如果1分钟和5分钟的平均负载超过了服务器物理CPU核心数的1.2倍（中小互联网非计算密集型场景的个人 阈值），就算CPU总使用率只有60%，也得赶紧排查是不是进程死锁或者并发数过高了。上个月的另一个小坑就是我们的一台图片服务器，%wa持续在22%晃，我一开始没当回事，觉得总CPU才50%，结果第二天图片批量裁剪任务直接跑崩，所有老用户的头像加载不出来。

然后说说内存监控，也别只盯着free -m或者htop里的“used”内存占比，Linux系统本来就会把空闲内存拿来当缓存（cache）和缓冲（buffer）用，used高不等于内存不够，看available内存（也就是free命令里的“available”字段，不是“free”） 才是王道，available内存是系统真正能随时分配给新进程的内存，个人 中小电商或者社交类场景的阈值设为物理内存的15%，低于这个数赶紧排查是不是有内存泄漏的进程。对了，这里给新手运维一个小的实操命令，排查内存泄漏进程非常好用：ps aux sort=-%mem | head -n 10，这个命令会按内存使用率从高到低排序，列出前10个占用内存最多的进程，之前我们的后端小老弟写的图片压缩代码有内存泄漏，就是靠这个命令10分钟找到的。

第三个烂大街但同样没被好好关注的是磁盘监控，别只看“df -h”里的磁盘容量占比，容量占90%以上才扩容或者清理日志是基本操作，但如果inode（索引节点）占比超过85%，就算磁盘容量还有一半，也会导致系统无法创建新文件，直接502或者500。我们公司去年双11大促前2天，测试服务器的inode就满了，原因是前端同事打包的时候没清理node_modules里的临时文件，生成了几百万个几KB的小碎文件，inode直接从30%飙升到98%。排查inode满的问题也有简单的命令：df -i 可以看各个分区的inode使用情况，find / -xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -n 可以找到inode占用最多的目录，这个命令里的“/ -xdev”是为了避免扫描其他挂载的分区，新手运维记得加上，不然会很慢。

第四个和第五个是很多新手完全没碰过或者碰过但没设阈值的常用指标：ESTABLISHED状态的TCP连接数和系统最大进程数（ulimit -u）。中小电商或者社交类场景，ESTABLISHED状态的TCP连接数如果持续超过服务器物理CPU核心数的200倍（个人 的保守阈值），就得赶紧排查是不是有恶意攻击或者后端代码写得有问题没有及时释放连接；系统最大进程数如果接近或者超过当前的ulimit -u设置，系统就会拒绝创建新进程，导致很多服务无法启动或者崩溃。上个月的预热测试的锅，恰恰就是这两个指标的问题：我们的集群最大进程数默认是1024，结果1000个种子用户涌进来，加上之前没清理的后台僵尸进程，系统最大进程数直接到了1023，新的请求进来根本创建不了新的Nginx worker进程，直接502；同时ESTABLISHED状态的TCP连接数也到了12000多，超过了我们48核服务器的200倍阈值（9600），但因为我们没给这两个指标设告警，所以完全没发现。

说了这么多，可能有些兼做运维的后端小老弟会问，这些指标怎么加到监控里设阈值啊？其实很简单，就拿我们常用的Prometheus+Grafana来说，CPU的%wa和load average、内存的available、磁盘的容量和inode、TCP的ESTABLISHED连接数、系统的ulimit -u，这些都是Prometheus的node_exporter默认采集的指标，不用自己写额外的exporter，只需要在Prometheus的告警规则文件里加上对应的规则就行。比如ESTABLISHED状态的TCP连接数的告警规则：expr: node_netstat_Tcp_CurrEstab > 9600，然后设置成“严重级别红标，持续1分钟就发邮件和钉钉告警”就行。

最后再给新手运维两个专属的避坑提醒：第一个是监控阈值不是一成不变的，要根据业务场景的变化定期调整，比如双11大促前，可以把ESTABLISHED状态的TCP连接数的阈值临时调到物理CPU核心数的400倍，把available内存的阈值临时调到物理内存的5%，等大促结束再调回来；第二个是别把所有的告警都发到同一个群里，最好分生产、测试、开发三个群，生产群的告警设置成“钉钉@所有人+手机短信通知（至少两个人）”，测试群和开发群可以设置成“群消息免打扰+严重级别红标”，不然真的会被没用的告警淹没，最后连生产的重要告警都忽略了。

你们在运维工作中有没有遇到过类似的“监控白搭钱还搭时间”的坑？欢迎在评论区分享你的排查经验。