Linux故障排查实战指南：从告警定性到根因定位的完整链路

凌晨两点多，手机震动把我从梦里拽出来，监控大屏刷了十几条告警：内存使用率飙到93%，某个核心接口成功率掉到50%，磁盘IO延迟翻了快三倍，工作群里已经有人在@全员。这种场面，干过运维和SRE的朋友大概率都不陌生。说实话，故障排查最大的难点从来不是缺命令，而是告警一多你就被牵着鼻子走，东看一眼西摸一下，最后半小时过去连故障域都没锁死。我这几年处理过上百起生产环境事故，越来越确信一件事：手里有没有一张清晰的Linux故障排查“作战地图”，直接决定你是十分钟恢复还是折腾到天亮。

这篇内容不是Linux命令大全的堆砌，而是把高频故障按存储、网络、进程资源、内核安全几个域拆开，每一类都给出从现象判断、命令定位到最终处置的完整链路。适合刚接手服务器的新人，也适合想把自己的排查流程体系化的运维和SRE朋友。照着这张图走一遍，至少能保证你在告警炸锅的时候，手脚不乱。

1. 告警响起的头10分钟：先定性，再动手

1.1 五类高发故障的特征速判

告警铺天盖地时，最忌讳的是直接盯着某一条看。我的习惯是先花两三分钟给故障定性。你不需要立刻知道根因，但你得知道它大概在哪个层。下面这张表基本覆盖了我遇到过的大多数情况：

注意load average这个数字，它是最容易被误读的指标。很多人看到load到了四五十就以为CPU爆了，其实load统计的是处于可运行状态和不可中断睡眠状态的进程总数，也就是说，一个进程卡在磁盘IO等待上，同样会拉高load。后面我在进程资源那部分会细讲怎么区分。

1.2 现场快照：故障在线时抢下来的数据才有复盘价值

我见过太多人，一上来就急着重启服务。服务是恢复了，可告警的根本原因永远成了悬案。正确的姿势是在动手之前，先做一次现场快照。所谓快照，就是一组能反映系统当前状态的命令合集，按顺序跑一遍，输出重定向到文件里，这就是之后复盘和定位的第一手证据。

我的固定流程大概是这样的：

bash复制date >> /tmp/syscheck/$(date +%F_%H%M).log
{
echo "===== load ====="; uptime
echo "===== mem ====="; free -h
echo "===== disk space ====="; df -hT | grep -v tmpfs
echo "===== inode ====="; df -i | grep -v tmpfs
echo "===== top process ====="; top -bn1 | head -30
echo "===== io stat ====="; iostat -x 1 3
echo "===== network ====="; ss -lntp
echo "===== log tail ====="; dmesg -T | tail -30
} >> /tmp/syscheck/$(date +%F_%H%M).log

有人会问，这不就是几条命令拼在一起吗？对，但关键在于，这套动作必须在心态还能稳住的时候提前固化好，真到告警炸裂的深夜，你不需要思考，直接执行脚本就行。排错和做手术是一个道理，先保证“病人”的真实状态被记录，后面不管怎么折腾，都不至于没有回头路。

2. 存储子系统：磁盘满、inode耗尽与“假满”的区分

2.1 df -h 正常却报 No space？先查 inode 与挂载点

存储类故障是深夜告警的重灾区，但坑也最多。最常见的一种情况是，服务端明明报了“No space left on device”，你跑完 df -h 却发现每个分区都还有不少剩余空间。这时候很多新手就懵了，其实问题常常出在两个地方：inode耗尽，或者你查的分区和服务实际写入的分区不是同一个。

inode是文件系统用来记录文件元数据的索引节点，每个文件或目录都要占用一个。如果分区里的小文件特别多，比如日志切割、邮件队列、PHP session临时文件，inode是会用完的。判断方法很简单，一条命令的事：

bash复制df -i

如果IUse%飙到100%，哪怕磁盘还有几GB剩余，你也创建不了任何新文件。处理思路一般是找到小文件扎堆的目录清理掉，比如 find /var -type f -size -1k | wc -l 这类方式先估算规模，再决定是直接清理还是归档。

另一个容易被忽略的是挂载点。df -h 默认显示所有挂载点，但你得确认服务实际写的是哪块路径。我处理过一次容器日志写满根分区的案例，服务挂在 /data 下，而 /data 是一个独立的数据盘，df看 /data 还剩一半，可日志其实是写到容器overlay层下的 /var/lib/docker，也就是根分区。所以排查时一定先proc或lsof确认进程打开的路径到底落在哪个挂载点上，别想当然。

2.2 删除文件后空间没释放：找出 still-open 的 deleted 文件

这个场景在热搜词里反复出现，包括WSL环境下删了文件空间不释放，生产Linux服务器上同样常见。表象是：df -h 看到某个分区已经满了，你 rm 掉一个大文件，再 df 一看，剩余空间居然没怎么变化。很多人第一反应是文件没删干净，其实多半是文件被某个进程打开了。

Linux下文件可以被删除，但只要进程还持有它的文件描述符，磁盘空间就不会真正释放。排查命令很固定：

bash复制lsof +L1 | grep deleted

+L1 的意思是显示link count小于1的文件描述符，也就是已经被删除但仍被进程打开的文件。找到之后，你看到的通常是这样的行：

code复制java  1234  user  16u  REG  253,0  8589934592  1048577  /var/log/app.log (deleted)

这时候处理方式有两种。如果能重启进程，那空间自然释放；如果服务不能随便重启，还有一个快速止血的办法：直接清空 /proc/<PID>/fd/<FD> 这个路径。比如上面这个例子，执行：

bash复制: > /proc/1234/fd/16

文件描述符对应的空间会立刻被释放，且不影响进程继续写。这个技巧在数据库、Java应用这类不方便重启的场景里非常好用。WSL那边的情况稍微特殊一点，除了进程占用之外，还涉及虚拟磁盘文件（vhdx）的碎片不回收机制，但思路是一样的：先用lsof排除进程占用，再考虑是不是vhdxtool这类宿主层工具的问题。

2.3 解压乱码与字符集问题：不是“系统坏了”，是编码没对上

解压文件乱码，看起来是个小问题，但真能把人折腾疯。尤其是从Windows传过来的zip压缩包，在Linux下用 unzip 一解压，文件名全变成乱码。这其实不是文件坏了，而是Windows下zip默认用的是GBK/GB18030编码，Linux下的unzip默认按UTF-8解包，两边对不上。

处理方案分版本。比较新的unzip版本支持 -O 参数指定编码：

bash复制unzip -O gbk 你的压缩包.zip

如果unzip版本太老不支持 -O，可以改用7zip：

bash复制7z x 你的压缩包.zip

7z在面对非UTF-8编码文件名时兼容性普遍更好。至于解压7z文件本身，老牌命令就是 7z x file.7z，如果是分卷压缩就 7z x file.7z.001。至于tar.gz包里的文件内容乱码，那又涉及文件内容本身的编码问题，查的时候可以用 file 命令确认编码，再用iconv转换，跟文件名乱码不是一个层面的问题，别混为一谈。

还有个很容易踩的坑是 LANG 环境变量没设置好。有些程序在 LANG=C 或者 POSIX 环境下输出中文会显示成乱码，甚至启动报错。我习惯在脚本开头显式声明 export LANG=en_US.UTF-8 或 zh_CN.UTF-8，根据目标用户来定，避免后续一堆连锁问题。

3. 网络故障的逐层排查：DNS、TCP连接与KVM虚拟化网络

3.1 DNS解析异常：resolv.conf被改写的坑

DNS故障在告警里非常隐蔽，表现往往是“服务偶发超时”或者“明明IP能通，域名就是解析不了”。如果你去查 /etc/resolv.conf，大概率会看到它已经被某种机制接管了。现在主流发行版里，NetworkManager、systemd-resolved、netplan都可能动态改写这个文件。

典型的坑是，你手工修改了 /etc/resolv.conf，过一会儿重启网络服务，改动又没了。这是因为在现代systemd环境下，/etc/resolv.conf 通常是一个软链，指向 /run/systemd/resolve/stub-resolv.conf，而真正的实际生效配置由systemd-resolved管理。光改一个软链是没用的。

排查DNS问题我建议按这个顺序走：

bash复制# 查看当前生效的DNS配置
resolvectl status

# 确认系统解析结果
getent hosts yourdomain.com

# 用指定DNS服务器查询
dig @8.8.8.8 yourdomain.com +short

# 查看详细解析过程
dig yourdomain.com +trace

至于修复，不要直接 vi resolv.conf，而是通过你的网络管理工具来改。比如NetworkManager环境用 nmcli connection modify 设置dns，systemd-networkd环境改netplan或对应的.network文件，然后再 systemctl restart NetworkManager。这套流程看起来绕，但恰恰是减少“改了又被覆盖”这类鬼故事的正确做法。

3.2 TCP连接状态与队列溢出：ss和tcpdump的配合

网络层另一个高发问题是连接建立异常。服务明明活着，端口也开着，但客户端就是连不上，或者连上了但请求卡住。这时候 ss 是你的第一手工具：

bash复制# 查看监听状态和对应进程
ss -lntp

# 查看当前所有连接状态统计
ss -s

# 查看某一端口的连接队列情况
ss -lnt | grep :8080

这里有一个特别值得注意的点：Recv-Q 和 Send-Q 在监听状态下不是字节数，而是代表accept队列和全连接队列的积压情况。如果Recv-Q持续非零且很大，说明有连接请求进来但应用没来得及accept，通常是应用层处理能力不足或卡住了。配合 ss -lnt | awk '{print $1, $2, $3, $4}' 观察SYN-RECV状态堆积，还能判断是不是半连接队列溢出。

如果到这一层还定位不了，就得抓包了。tcpdump用起来不复杂，关键是带着问题去抓：

bash复制tcpdump -i eth0 host 目标IP and tcp port 8080 -nn -c 100

抓包后看的是TCP三步握手有没有完成。如果只有SYN没有SYN-ACK，说明数据包到了中间某层就被丢了；如果有SYN-ACK但客户端没回ACK，那多半是客户端侧的问题。这种逐层确认的思路，能帮你避免“明明出在对方网络上，却在本地瞎折腾半天”的尴尬。

3.3 KVM虚机网络问题：先分清NAT与网桥

涉及到KVM虚拟机，网络排查多了一层复杂度。很多虚拟机“突然连不上网了”，其实是宿主机的libvirt网络在搞鬼。默认安装完libvirt之后，会有一个 virbr0 网桥，虚拟机走的是NAT模式。如果宿主机上的 libvirt-daemon 服务重启或者异常退出，virbr0 接口可能就没起来，虚拟机自然就断网了。

排查顺序建议这样：

bash复制# 查看虚拟网络状态
virsh net-list --all
virsh net-info default

# 查看宿主机网桥
ip addr show virbr0
brctl show

# 检查NAT转发规则
iptables -t nat -L POSTROUTING -n -v
iptables -L FORWARD -n -v

常见的坑是FORWARD链默认DROP，或者libvirt服务启动时iptables规则没重建。另外，如果你把虚拟机改成桥接模式直接接入物理网络，那就要确认宿主机的物理网卡有没有 eth0 和 br0 正确桥接，桥里有没有加入对应的tap接口。别一上来就查虚拟机内部的路由，先确认虚拟化层的链路通不通，这个顺序很重要。

4. CPU、内存与进程三重奏：别被告警数字带偏

4.1 负载高不等于CPU忙：D状态进程与iowait的判断

我把这一节放在网络后面，是因为进程资源类故障最容易让人“看着告警做错误判断”。比如load average飙升到200，你打开top一看，CPU使用率才不到10%，整个系统像死了一样卡住，这绝对不是CPU瓶颈，而是系统里有大量进程进入了D状态，也就是不可中断睡眠状态。这种状态通常是因为进程在内核态等待某个资源，最常见的是磁盘IO——比如NFS挂载点失联、磁盘坏道导致的IO卡死。

判断方法很简单：

bash复制top -bn1 | awk 'NR<=20 {print}'

看进程的S列，如果一堆 D，基本可以锁定IO问题，再用 iostat -x 1 看看每个磁盘的 %util 和 await 指标。await 长期居高不下，说明磁盘响应很慢；w_await 高则是写路径卡顿。这里特别提醒一下，D状态进程是kill不掉的，你用kill -9也是白费力气，因为进程压根不响应信号，正确做法是修复底层IO问题，比如恢复NFS连接或硬重启出问题的磁盘。

还有一种特殊情形是极少数安全软件或EDR代理在内核层挂钩子，导致某个系统调用处理得特别慢，也会制造出大量D状态进程。这种情况排查起来比较隐蔽，我看下一步再说。

4.2 内存告警与OOM Killer：先分清page cache还是真泄漏

内存告警有个经典误判：看到 free -h 里面used特别高，就断定内存泄漏了，要加内存。其实Linux的内存管理哲学是“尽可能利用空闲内存做page cache”，这部分内存看起来被占用了，但只要应用需要，内核会立刻回收它们。真正需要警惕的是两种情况：一是swap被大量使用，说明内存确实吃紧；二是 free 里available数值很低，说明内核可回收的余地已经很小了。

当你看到内存告警同时伴随服务进程消失，第一个要查的就是OOM Killer：

bash复制dmesg -T | grep -i "out of memory"

找到类似 Out of memory: Killed process 1234 (java) 的记录，后面会附带这个进程当时的内存占用评分。再结合 journalctl --since "1 hour ago" | grep -i oom 看系统日志里有没有更多上下文。

判断是否真泄漏，不能只看瞬间内存值，要看趋势。我习惯用这样一个命令循环采样，观察半小时：

bash复制for i in {1..30}; do
  ps -o pid,rss,vsz,cmd -p 目标PID
  sleep 60
done

RSS持续单调上涨且不回落，才叫泄漏；如果有涨有跌属于GC回收或正常波动。内存排查最大的忌讳是“凭感觉判断”，没有数据支撑的结论，大概率是错的。

4.3 僵尸进程与无法kill的进程：问题在父进程，不在子进程

僵死进程（Zombie）排错上有个很反直觉的点：你拿 kill -9 去杀僵死进程，永远杀不掉。因为僵死进程本身已经死了，它的内核栈都释放了，只是进程表里还剩一个entry，等着父进程来 wait() 它。换句话说，问题不在子进程，而在父进程不回收。

用 ps -ef | grep defunct 找到僵死进程，再看它的PPID是谁。如果父进程还活着，那你得检查父进程为什么没有调用wait。常见原因有：父进程代码bug、父进程本身卡在D状态、或者容器环境里PID 1进程没有实现子进程回收逻辑（这是容器里zombie泛滥的头号原因）。不过在systemd管理的主机上，大多数进程的父进程init会自动收养并回收孤儿进程，所以看到个别僵尸进程可以先观察，不必拼命清。

比僵尸进程更麻烦的是刚提到的不可中断进程，它们连信号都收不了。我见过一个案例，进程卡在D状态是因为它读了一个存放在NFS上的文件，而那个NFS服务端恰好挂了，客户端又没配 soft 挂载选项，默认 hard 模式导致进程无限期等待。后来把挂载方式改成 soft,timeo=50,retrans=2，同样场景下进程顶多报个错就退出了，不会卡死整个服务。

5. 内核与安全机制引发的“诡异”故障

5.1 dmesg日志是内核的“黑匣子”

说到这我得劝一句：前面那些常规手段都排查不出结果的“诡异”故障，十有八九最后都要靠内核日志一锤定音。dmesg 就是内核的“黑匣子”，它记录着驱动加载、硬件错误、文件系统错误、OOM、软死锁等信息。排查这类问题的基本动作是：

bash复制# 查看最近的内核错误
dmesg -T -l err

# 查看告警级别日志
dmesg -T -l warn

# 持续跟进
journalctl -k -f

-T 参数特别重要，它把内核时间戳转换成可读时间，不然你看到的是一串从开机开始计的秒数，不好对应告警时刻。我处理过一台服务器频繁重启的案例，应用日志一切正常，最后看dmesg才发现是NVMe SSD的固件报了大量I/O错误，系统不得已把文件系统挂载成只读，随后才引发一系列连锁反应。类似这种硬件和驱动层面的信息，常规命令根本看不到。

5.2 文件读写被动态拦截：透明加密与系统调用挂钩

有些环境的故障特别怪异：服务正常、磁盘空间充足、负载也不高，但某些文件就是读不出来，或者读出来的内容对不上。这时候要怀疑是不是有内核模块在“从中作梗”。我指的就是类似 file_operations 结构体里的 read、write 指针被动态替换这种机制，很多安全软件、透明加密驱动、沙箱审计工具都会这么干。

举个例子，透明加密系统会在文件被应用读取时，在内核态动态解密，返回明文；而当进程把文件拷到U盘这类外部介质时，有些实现会不加解密直接返回密文。从应用视角看，症状就是“为什么同一个文件，换个地方读内容就不一样”、“为什么grep不到关键词”，非常让人头疼。

遇到这种情况，第一反应别是这事有鬼。先用 lsmod 看内核模块列表，再用 dmesg 查模块加载时间线，重点关注业务异常发生前后有没有新模块被加载。如果模块来自安全或加密厂商，一般能在启动日志里找到它的加载记录，也能在 /sys/module/<模块名>/parameters/ 下看到具体参数。作为运维，你不需要能改写这个LKM，但你需要识别它的存在和影响范围，否则会在这类问题上耗掉整晚。

顺带说一句，这类内核层挂钩如果实现得有bug，也常常表现为“某个进程莫名进入D状态”、“read调用返回EIO”或者“CPU内核态占用高得离谱”。所以当你遇到三种症状叠加时，优先怀疑内核模块，而不要再死磕应用代码了。

5.3 用户与权限的隐蔽风险：新建用户、SUID与提权告警

深夜告警里还有一种容易被忽略的“安全类”信号——系统里突然多了一个用户，或者某个二进制文件的权限被改动。很多人收到这类告警会当误报忽略，但如果你把账号权限管理和故障排查合并到一张图上，会发现它们其实是同类问题：系统整体的健壮性和安全性是绑在一起的。

先说不容易出错的基础操作。新建用户时，我通常会加上过期和shell限制：

bash复制useradd -m -s /bin/bash -e 2025-12-31 新用户名
passwd 新用户名

用 usermod -aG wheel 或编辑 sudoers.d 单独授权，而不是直接把用户加进root组。排查账号安全隐患时，重点关注这几件事：

bash复制# 查找所有SUID文件，这是提权的经典路径
find / -perm -4000 -type f 2>/dev/null

# 对比系统账号变化
awk -F: '$3==0 {print $1}' /etc/passwd

# 查看最近登录
last -20

Uid为0的账号不只有root，只要某个账号的第三字段是0，它就拥有root权限。这是排查“为什么某个普通用户能提权”时的头号检查点。平时我还会打开auditd审计日志，遇到可疑行为时能追溯到具体用户和命令，这个习惯在追查内部问题时特别值钱。安全防御不是单独的一个动作，它应该嵌入到你的日常巡检清单里，和磁盘、内存、网络处于同一个优先级。

6. 实战复盘：从一次写入故障看完整排查闭环

6.1 一次“写入失败”告警的全过程

前面讲了很多零散的点，这里我把它们串成一个完整案例。之前遇到过一次比较典型的告警：凌晨1点，某个应用开始疯狂报错，集中在文件写入失败上。按经验我第一反应是磁盘满了，跑了下 df -h，发现 /data 分区只用了60%。但我没有停在这一条结果上，而是顺手跑了 df -i，好家伙，inode用完。

当时我判断是文件数量过多导致inode耗尽。找了一圈，发现应用在一个目录里写了上百万个临时文件。但问题来了：为什么inode会耗尽得这么快？正常来说要写几百万个文件才能触顶，这明显不符合应用的正常行为。我回头查看应用日志，发现某个线程在死循环生成临时文件。清理完临时文件之后，又确认了一遍磁盘帮助命令，确认空间和inode都恢复正常。

这个案例技术含量不高，但很能说明这套“作战地图”的价值：df -h + df -i 两条命令同时看，省掉了我一个人在那边瞎猜的时间。如果我只看到磁盘空间充足就调头去查别的，那一整晚都会在那个死循环上面打转。

6.2 把这套地图固化成每日巡检与复盘模板

这类经验沉淀下来之后，我给自己配了一个简单的每日巡检脚本，语法不复杂，但足以把多数隐患拦在白天：

bash复制#!/bin/bash
# 基础巡检，放到cron里每天跑一次
echo "===== 巡检时间: $(date) ====="
uptime
free -h | grep -E "Mem|Swap"
df -hT | grep -vE "tmpfs|overlay" 
df -i | grep -vE "tmpfs|overlay"
echo "===== 当前异常进程数 ====="
ps -eo stat,pid,cmd | awk '$1 ~ /D|Z/ {print}'
echo "===== 日志中的关键错误 ====="
journalctl --since "-24h" -p err --no-pager | tail -20

每次故障处理完之后，我也要求自己和团队成员必须回答三个问题再去睡觉：这个故障真正的根因是什么？现有监控为什么没有提前发现？下次遇到同样问题，我们能不能在十分钟内完成定位？这三个问题听起来简单，但把这三条坚持下来，排查能力是肉眼可见地在涨。

最后分享一个我个人的经验：遇到不熟悉的故障，哪怕心态很急，也要强迫自己按顺序把现场快照跑完再看日志，时间绝对花得值。这套排查体系不是一天堆出来的，但一旦你把它变成身体记忆，深夜接到告警电话的时候，你会发现，自己比想象中稳得多。