Linux服务器告警响应指南：CPU内存磁盘网络故障排查实战

凌晨一点四十七分，手机连续震动七次。朋友圈里有人刚发了张截图，监控面板上一片红。如果你也是那个被“Linux服务器磁盘使用率超过90%”从睡梦中叫醒的人，就会明白这串告警意味着什么——它不是一条冷冰冰的消息，而是一张需要立刻行动的牌。

我处理过的多数“深夜告警炸裂”，最后都能追到几个固定的根源上：文件句柄耗尽、inode爆了、TCP连接堆积、某个进程悄悄把内存吃穿。这些事本身不难查，难的是你在半睡半醒的状态下，能不能在最短时间里理出一个清晰的排查路径。这篇东西不是给你背命令的，而是帮你建立一套自己的“作战地图”：从告警响起的那一秒开始，先做什么，再做什么，哪些命令组合起来能一句话定位到根因。无论你是刚接手Linux服务器运维，还是已经在生产环境摸爬滚打几年，这套思路都能让你的故障排查从“救火”变成“按图索骥”。

1. 告警风暴面前，先分诊再动手

1.1 三种常见告警类型，决定你要不要立刻爬起来

深夜的告警最怕两种情况：一是不知道它有多严重，二是觉得每条告警都很严重。前者容易把小事拖大，后者容易让你在错误的路上浪费半小时。我的经验是先把告警分成三类来看。第一类是可用性告警，比如主机ping不通、SSH连不上、某个核心端口探活失败，这种基本没有商量余地，得立刻处理。第二类是性能告警，像CPU使用率过高、负载飙升、内存占用超过阈值，这类要结合持续时间和趋势判断，五分钟的毛刺往往不用理会，持续二十分钟以上才值得动手。第三类是容量类和日志类告警，磁盘空间、inode、文件句柄、日志里出现的异常关键字，这类通常不会让服务瞬间挂掉，但如果不处理，迟早会变成第一类。

分诊的关键在于你手边是不是有历史基线。我见过不少人凌晨被一条CPU 90%的告警惊醒，上去一看是监控脚本自己跑批引起的，平常这个点就有规律波动。所以真正负责的运维会把监控阈值和历史数据一起看，而不是孤立地盯着一串数字。如果你手头没有基线数据，先别急着重启服务，去看这十分钟的监控曲线是陡然拔高还是缓慢爬升，这能帮你判断是突发故障还是积累型问题。

1.2 留好时间线，比马上敲命令更重要

很多人接到告警的第一反应是冲上去敲命令，这个习惯得改一改。深夜处理故障，最好的工具不是键盘，而是一张能记录时间线的小本子，或者你手机备忘录里的一行字。我自己的习惯是先把三个信息记下来：告警首次触发时间、最近一次业务发布或配置变更时间、监控图上异常开始的时间点。这三个点一对照，很多问题的排查范围能直接缩小一半。

举个真实例子。前阵子公司一台Nginx节点凌晨报“连接数超过阈值”，同事顺着连接数一路查TCP参数、调内核配置，折腾了四十分钟没结果。我让他去翻发布记录，发现当天下午刚上线了新版本网关，新版本默认keep-alive超时和旧配置不一致。问题压根不在Linux内核参数上，而是应用层连接复用策略变了。如果当时先花两分钟确认变更窗口，就能省掉后面一整轮无用功。记住这句话：故障排查里最贵的不是命令敲得慢，而是方向选错了还在埋头跑。

2. 性能类告警的定位三板斧：CPU、内存、负载

2.1 CPU打满：先分清是用户态忙还是内核态忙

CPU告警是所有性能问题里最容易被误判的。很多新手一看到CPU 100%就想着“杀进程”，但进程是无辜的，CPU高只是症状，你得找出是谁在消耗它，以及它消耗CPU在干什么。我登录服务器后的第一轮命令通常是top加vmstat组合，先看整体再看细节。

top进去先按一下P，让进程按CPU使用率排序，看看排在前面的是哪个进程，这条命令两秒钟就能给出目标。但如果进程列表看着正常，机器负载却很高，就要用vmstat 1 5去看采样结果。这里有个关键技巧：看us和sy两列的比例。us高说明是用户态程序在拼命计算，常见于死循环、糟糕的正则回溯、GC频繁；sy高说明内核态占用多，常见于系统调用过密、锁竞争、中断处理太多。还有一种情况是wa列飙高，那说明CPU在等磁盘I/O，算是个假高，实际上瓶颈在存储。

我去年排查过一个Java服务CPU飙升的问题，top里显示的是GC线程占了300%多CPU，但业务线程没几个活跃。当时第一反应是堆内存不够导致频繁Full GC，上去调了Xmx