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参数，重启后确实好了半小时，然后又复发。后来用jstat盯着看了几分钟才发现是老年代持续增长，根源是有个定时任务在循环查一张没建索引的大表，把内存慢慢撑爆。CPU排查到这里，一定要往应用逻辑层多想一步，不能系统层看到啥就改啥。

2.2 内存告警的处理：别被buff/cache骗了

Linux的内存管理跟Windows思路不一样，它会把空闲内存尽量拿来当page cache用。所以你在free -h里看到used很高、free很低，不代表内存真的紧张，要看的核心指标是available，这列才是“还能给新进程用多少”的真实描述。如果available还占总量20%以上，这个内存告警基本可以降级观察。

真正需要紧张的是两种内存场景。第一是进程内存持续上涨，常见于Java堆设置不合理、Redis的maxmemory没限制住、或者代码里有map只增不减。第二是系统开始用swap，或者直接触发OOM killer。排查前者可以用pidstat -r 1 5看具体进程的内存变化率，用ps aux --sort=-%mem把内存占用排序拿出来对比，重点看RES列——如果你看到某个进程的RES远大于它业务上该用的量，八成是内存泄漏了。排查后者要去看dmesg -T | tail -50，内核会在OOM发生时记录是哪一进程被杀、当时的内存情况，日志里记得清清楚楚。

这里有个实用知识点：很多服务器默认没有配swap，或者配置得很小，但系统内存还有个“committed”的概念。你用cat /proc/meminfo看Committed_AS和CommitLimit，如果Committed_AS已经接近甚至超过物理内存总量，说明系统里大量进程申请了虚拟内存但没真正使用。这种时候某个进程突然开始大面积写内存，OOM killer就会冒出来，哪怕你free看着还有空间。遇到这种告警，除了排查进程本身，还得回头审视一下有没有超卖内存的部署方式。

2.3 Load Average暴增：千万别只盯CPU

load average这玩意儿是最容易引起误判的指标之一。它的含义是“处于可运行状态和不可中断睡眠状态的进程平均数”，也就是说，它不止包含在CPU上跑着的进程，还包含在等磁盘I/O、等网络I/O的进程。所以我见过很多场景：CPU使用率只有20%，load average却到了20多，整个服务卡得不像话。

遇到这种“负载高但CPU不高”的畸形状态，第一步要做的是确认有多少进程处于D状态。你可以执行ps -eo state,pid,cmd | awk '$1 ~ /D/ {print}'这条组合，当D状态进程数持续大于零，基本就能锁定是I/O等待拖垮了负载。接下来用iostat -x 1看看是哪块磁盘在扛不住，重点看%util和await两列。如果%util长期90%以上，说明磁盘真的到了瓶颈；如果%util不高但await很高，可能是有大量随机读写或者磁盘队列堵塞。

再说一个进阶技巧：现代内核提供了PSI（Pressure Stall Information）接口，路径在/proc/pressure/。里面有cpu、memory、io三个文件，记录了资源争抢导致任务停顿的比例。比如/proc/pressure/io里的avg60如果超过5%，哪怕iostat看起来不严重，也说明系统已经有相当比例的进程在等I/O了。这个指标能帮你识别出那些“指标看着还行，但用户感知就是卡”的隐蔽故障，用起来比传统工具直观得多。

3. 容量和文件系统引发的“假死”现场

3.1 磁盘满不一定是真满：inode耗尽是个经典坑

“No space left on device”这条报错，是所有运维都见过的经典坑。但如果你df -h一看还有几十G剩余，就很容易懵住：明明有空间，为什么写不进去？这时候请记住第二板斧：df -i。这个命令看的是inode使用率。Linux系统写文件要同时申请数据块和inode（可以理解为文件的“索引条目”），如果inode分配光了，就算磁盘容量再大也写不进新文件。这种情况在有小文件大量生成的目录里特别常见，比如邮件队列、PHP session目录、消息队列的spool目录。

我之前救过一次这样的故障：客户那边有个应用要写临时文件，突然全线报错，df -h显示根分区还剩下15G，谁也想不到是inode满了。我上去执行df -i一看，/dev/vda1的IUsed已经到100%。再用for i in /var/spool/*; do echo $i $(find $i | wc -l); done这种循环定位到具体目录，发现是一个守护进程异常退出后留下的几十万个小锁文件。处理方式很简单：确认进程已经停了，然后批量删除这些残留文件，分分钟恢复。从此以后，我把df -i加进了所有磁盘告警的处理步骤里，这条经验值很大。

3.2 文件删了空间没释放？找还在握着文件句柄的进程

还有一种情况比inode更隐蔽：你执行df -h，发现磁盘使用率明明降下来了，但监控面板还是红的；或者正好反过来，监控一直报磁盘满，你删掉一个大日志文件，使用率却没有变化。原因是那个文件虽然从目录里“消失”了，但仍有进程打开着它的文件句柄，内核不会真正回收磁盘空间，直到那个进程关闭文件或退出。

排查这类问题最快的命令是lsof +L1，它会列出所有被删除但仍有进程引用的文件。输出里如果出现deleted标记，并且文件大小那列不是0，就是这个文件霸占了空间。我处理过一个极端案例：有人用nohup重定向的方式启动Java进程，stdout写进了nohup.out，这个文件越滚越大，他直接rm掉之后，Java进程一直在运行，文件句柄没断，磁盘空间被白白占了几十G，服务还越来越慢。处理方案是把进程重启一下，或者通过gdb让进程关闭那个多余的fd，生产环境里大多数时候直接重启最省心。

顺手补充一个日常习惯：配置logrotate时，别忘了加copytruncate选项。因为很多应用启动后不会重新打开日志文件，你用常规方式rotate掉日志文件，应用的fd还指向原来的inode，新旧日志继续写到已删除的文件里，就会复现这种“删了还占空间”的诡异事故。要不要重启服务取决于你的场景，但copytruncate能让你在大多数情况下免掉重启。

3.3 文件句柄和线程数被“薅光”：系统资源比磁盘更容易枯竭

文件句柄（fd）不够用也是深夜告警里的大户，表现是进程日志或系统日志里出现“too many open files”。这类问题往往和突发的连接风暴或代码bug有关，比如HTTP客户端没设置连接池上限、数据库连接没释放、某些框架内部频繁创建文件临时器。排查时先看全局：cat /proc/sys/fs/file-nr，第一个数字是已分配句柄，第二个数字是空闲句柄，第三个是总上限。如果第一个数接近第三个数，说明整个系统层面的fd都快耗尽了。

要找出具体是哪个进程在疯狂占fd，可以用ls /proc//fd | wc -l统计每个进程的句柄数，也可以直接用lsof -p | wc -l。找到可疑进程之后，去应用侧查连接池配置，别只是把ulimit调大。另一个容易被忽略的资源是线程数，进程的线程数可以通过ls /proc//task | wc -l来看，系统对线程数的限制在/proc/sys/kernel/threads-max和/etc/security/limits.conf两个层面。如果你用systemd管理服务，还要在service文件里检查LimitNOFILE和TasksMax，这两个参数不写的话，默认值可能比你想的低很多。改完之后记得daemon-reload并重启服务，只ulimit -n是只对当前shell生效的，这点新手最容易弄错。

4. 网络连接类告警：连接数高和连接异常要分开看

4.1 连接数飙升：先看流量入口再看TIME_WAIT

网络连接类告警是“炸得最响”的一类，因为监控图上通常会画满红线。但拿到告警先别慌，第一步是确认到底是哪种“高”。如果是活跃连接数高，说明有真实流量或者业务在频繁建连；如果只是总连接数高，里面TIME_WAIT或ESTABLISHED占一大半，那背后的逻辑完全不同。

排查时我先用ss -s看整体连接状态统计，再用ss -tan结合awk按状态和远端IP统计，能快速看出是谁在跟你建连接。这里有个容易被误判的点：TIME_WAIT多并不一定代表服务出问题，它是TCP主动关闭方进入的稳定状态，为了可靠性和防止旧包串扰而存在，通常几十秒后自动消失。只要系统日志里没有大量“time wait bucket table overflow”的报错，就不用管它。但如果你发现某个后端服务的TIME_WAIT数量异常高，说明这个服务在频繁地主动关闭连接，问题往往出在HTTP keep-alive没生效、短连接风暴，或者Nginx和后端之间upstream配置了http/1.0。

另一个值得重视的指标是SYN_RECV状态高。它代表连接请求已经发出但三次握手没完成，多半是并发量真的太大，抑或是有人在用半连接方式打你的服务。配合netstat -s看SYN_Sent重发次数，如果数字疯长，就要考虑是不是遇到流量攻击了。此前我处理过一个Nginx节点，告警显示连接数从几千涨到十万级，ss -tan统计发现90%是来自同一批IP的SYN_RECV，后续的处理是加防火墙规则限制并发、调高syn_backlog、缩短SYN超时时间。这类问题不在参数上纠结太久，先挡流量再聊优化。

4.2 容器和K8s场景下的网络排查顺序

如果你的业务跑在Kubernetes里，网络告警的排查难度会上一个台阶，因为“这台Linux机器上的网卡流量高”和“这个Pod访问超时”可能是同一个问题的两面，也可能是不同的两件事。我现在遇到容器网络类的告警，习惯性的排查顺序是：先看Node节点的基础网络指标，再看Pod的网络策略，最后才进容器内部看应用。为什么是这个顺序？因为很多Pod网络故障的根本原因反而在宿主机层面，比如节点conntrack表满了、节点网卡软中断过高、或者kube-proxy的iptables规则被刷掉了。

具体操作上，有个经典场景是集群里某个服务频繁告警连接超时，但看Pod的CPU内存都很正常。这时候不能只盯着Pod，要上Node看一眼/proc/sys/net/netfilter/nf_conntrack_count和nf_conntrack_max，如果前者接近后者，就能解释为什么新连接总是被丢弃。原因通常是短连接太多，conntrack表被撑满，而默认的表大小又没跟着节点规格走。解决办法是调大conntrack max及对应hashsize，同时从业务侧看能不能减少无效短连接。另一类常见问题出现在DNS解析上，表现为Pod日志里大量“connection refused”或解析超时，但服务本身没问题。排查方向要落在CoreDNS或节点resolv.conf配置上，别在应用代码里白费力气。

4.3 从业务日志里抓出“嫌疑人”：一种反向定位法

有时候系统层面的指标全都很健康，但业务就是受损，这种告警最磨人。比如监控提示“最近五分钟5xx错误率超过5%”，你登上服务器看CPU不到10%，内存富余，磁盘I/O很低，网络也没有丢包。那问题大概率藏在应用日志里，你需要把工作模式从“查系统”切换到“读日志”。

我比较推荐的做法是先进日志目录看最近一段时间的异常聚集点，而不是盲翻整个文件。比如用grep -c去统计错误关键字在时间维度上的分布，把最近几小时的日志按小时切开来对比，可以定位出异常是从哪个时间点开始集中爆发的。如果是Java应用，先搜“OutOfMemoryError”、“Connection pool exhausted”、“SocketTimeoutException”这类关键异常；如果是Nginx入口，先按upstream_response_time排序，找出响应耗时超过几秒的请求，再看它们集中打到了哪个后端。这套反向定位法用在混合云架构里尤其有效：先通过日志把“嫌疑人”锁定到某个服务或某台机器上，后面再回去看那台机器的系统指标，基本能找到根因。

5. 常用命令速查表和深夜作战习惯

5.1 一页纸的Linux故障排查命令速查表

我不太主张背命令大全，但有几组组合是每个运维都应该形成条件反射的。这里整理成一张速查表，覆盖我前面讲到的几个主要故障场景。表格里的命令不追求全，追求“打出去就有用”，按场景采用即可。

写这张表时我刻意把命令收敛到最少，因为生产环境出故障时，人的注意力是有限的。工具一旦多了就会纠结到底用哪个，动作反而变形。每个场景下事先选好一个最趁手的命令，形成肌肉记忆，几分钟内就能把范围缩小。

5.2 深夜处理告警时的固定动作：先留存现场再介入

关于“深夜作战”，我有一条自己坚持了很多年的经验：任何操作之前，先留存现场。具体指的是——先把告警截图存到故障记录群里，把当时的监控曲线截图留底，把日志里最关键的时间段复制出来，然后才开始执行命令。为什么这么做？因为生产故障一旦开始处理，系统状态就会持续变化，很多线索转瞬即逝。等到第二天复盘时，你会发现当时随手截下的那张图，比任何人的回忆都可靠。

另一个固定动作是：优先做“无损排查”，再做“有损操作”。无损排查包括top、free、df、ss、日志查看这些只读命令；有损操作包括重启服务、清空日志、kill进程、修改内核参数。我见过太多人一上来就重启应用，以为能把故障带走，结果现场被破坏了，问题该出现还是出现，而且更难查。如果你判断某个进程确实要重启才能恢复，先执行ps和lsof把它的启动参数、依赖环境和占用资源记下来，再动手不迟。记住，一分钟的准备往往能省下第二天两个小时的返工。

5.3 每次故障后的复盘，比排障本身更重要，给你一份我的格式参考

故障处理完，不少人会松口气，把复盘拖到“有空再做”，然后就没有然后了。我不建议把这个环节省掉。深夜那一两个小时的折腾，本质上是花钱买经验，如果不把经验沉淀成文档和检查项，下次遇到类似问题还是要重新交学费。

我的复盘文档一般分几块：故障现象概述，先写清楚什么业务在什么时间点出现了什么症状；影响面评估，记录受影响的服务、请求量、时长；排查时间线，列出从告警到恢复的每个关键节点；根因分析，这一步要区分“技术近因”和“管理远因”，比如技术近因是磁盘写满，管理远因可能是日志轮转没配置对；最后是后续action，包括监控阈值调整、代码修复、操作流程变更，每个action都要指定负责人和截止时间。这套格式并不复杂，但带来的改变很明显：下次告警进来时，你能更快定位到“这问题我见过”，处理速度会快很多。

另外，我一直建议团队把每类告警沉淀成操作手册，写明第一责任人、升级路径、常用排查命令、历史故障备注。没有什么比一份经过实战验证的手册更能对抗深夜的焦虑了。它本质上就是给未来的自己留的一张作战地图。