Linux服务器故障排查的关键是”先定位，后处理，最后复盘”，乱重启只会掩盖问题。服务器运维日常高频故障集中在CPU高负载、内存不足、磁盘写满、网络异常四类。本文给出每类故障的排查命令、判断标准和处置步骤，照着做能少走弯路。

排查前的准备工作：确认时间线

动手之前先回答三个问题：故障从什么时间开始、最近改了什么配置、是否所有节点都异常。修改过内核参数、发布过新版本、调整过定时任务，往往就是故障源。同时把监控指标和系统日志同步导出。

# 确认负载与运行时间
uptime
# 最近的系统日志（内核级）
dmesg -T | tail -50
# 应用/系统日志目录
ls -lt /var/log/ | head

CPU高负载：top、vmstat与pidstat

先用top看整体负载，再逐层定位到进程和线程：

top -c -o %CPU          # 按CPU排序，看进程
vmstat 1 5              # us/sy/wa 判断是用户态、内核态还是IO等待
pidstat -p PID 1 5      # 进程内线程维度

us高是应用计算密集，sy高是系统调用/上下文切换多，wa高多半是磁盘IO在拖后腿。定位到进程后，用top切换H键看线程级，再用perf或gdb定位热点。常见处置：业务进程做优化或扩容，病毒/挖矿进程直接隔离杀掉。

内存不足与OOM处理

free -h看总量，结合slab和cache判断是否可回收：

free -h
dmesg | grep -i oom        # 找OOM Killer记录
cat /proc/PID/status | grep -E 'VmRSS|VmSwap'

OOM触发时内核会随机杀进程，Java服务常被杀掉。处理顺序：

1. 确认是否有进程内存泄漏，用smem排序。
2. 大堆服务检查-Xmx和容器内存配额是否匹配。
3. 短期顶不住可调vm.overcommit_memory或临时加swap，但长期还是扩容或优化。

磁盘空间不足与IO饱和

磁盘满是最常见的”假故障”：写入失败引发一串连锁报错。排查：

df -hT                   # 分区使用率
du -sh /* --max-depth=1  # 定位大目录
find / -size +1G -type f 2>/dev/null  # 大文件
iostat -x 1 3            # %util / await / 队列长度

日志文件、临时文件、备份文件是三大元凶。处理：清理过期日志（logrotate）、清空临时目录、压缩归档，最后扩容或迁移。IO饱和时先看await和util，确认是单盘瓶颈还是文件系统问题，再决定上SSD还是做RAID。

网络异常：连接数、丢包与带宽

ss -s                    # 连接统计
ss -tn state time-wait | wc -l
netstat -i               # 网卡丢包/错误计数
sar -n DEV 1 5           # 每秒网卡流量

time_wait过多通常是短连接压测或高并发访问，调net.ipv4.tcp_tw_reuse缓解；收到大量RST，先查防火墙和对方端口。带宽打满则用nethogs、iftop定位进程。

应用层故障：日志与慢请求定位

系统层没问题，重点转应用层：

tail -f /var/log/app/*.log | grep -i error
# 网关/中间件慢请求
grep -E 'timeout|5xx' /var/log/nginx/access.log | tail

把错误日志、慢SQL、GC日志三条线索串起来看，往往能直接指向根因。数据库慢查询用slow.log配合mysqldumpslow分析，GC频繁则查JVM堆和元空间。

故障处置顺序与复盘

处置顺序：先止损（回滚、重启、隔离），再定位根因，最后写复盘。复盘记录时间线、根因、处置动作、改进项，沉淀成故障应急手册。别在复盘里写”加强监控”这种空话，要落到具体的告警阈值和自动处理动作。