Linux故障排查实战指南：从基础命令到高级诊断

1. Linux故障排查"作战地图"：深夜告警的终极解决方案

凌晨三点，刺耳的告警声划破夜空。服务器CPU飙红、磁盘爆满、网络中断...作为运维工程师，这种场景你一定不陌生。面对复杂的Linux系统故障，慌乱地敲着各种命令却找不到问题根源？这份"作战地图"就是为你准备的。

我整理了15年运维实战中总结的Linux故障排查方法论，将零散的命令和检查点组织成清晰的排查路径。不同于网上零碎的教程，这是一套完整的应急响应流程，从告警现象直达问题根源，就像军事地图一样指引你快速定位战场关键点。

2. 核心排查框架设计

2.1 四层诊断模型

所有Linux故障都可以归类到以下四个层面：

1. 硬件层：CPU/内存/磁盘/网络设备等物理问题
2. 系统层：内核、服务进程、资源限制等
3. 应用层：具体业务程序的异常
4. 网络层：连接、防火墙、DNS等

排查时建议按照自底向上的顺序，先排除底层问题再检查上层应用。这就像医生诊断病人，先检查生命体征再分析具体症状。

2.2 黄金五分钟检查清单

接到告警后的前五分钟最为关键，建议按此顺序快速收集信息：

提示：将这些命令保存为check.sh脚本，赋予执行权限后一键运行

3. 深度诊断工具与技术

3.1 CPU问题排查实战

当top显示CPU使用率过高时：

1. 定位热点进程：

ps -eo pid,user,%cpu,%mem,cmd --sort=-%cpu | head -n 10

2. 分析具体线程：

top -H -p [PID] pidstat -t -p [PID] 1 5

3. 性能采样（适合Java应用）：

jstack [PID] > thread_dump.log perf top -p [PID]

常见问题：

• 用户态CPU高：通常是业务代码问题，检查热点函数
• 系统态CPU高：可能是系统调用频繁或IO等待
• 僵尸进程：检查父进程是否正确处理SIGCHLD

3.2 内存泄漏定位技巧

内存问题的典型表现：

• free显示可用内存持续下降
• 开始使用swap空间
• OOM Killer频繁触发

排查步骤：

1. 监控内存变化趋势：

watch -n 1 'free -h; echo; ps aux --sort=-%mem | head -n 5'

2. 检测内存泄漏工具：

valgrind --leak-check=full ./your_program pmap -x [PID] # 查看内存映射

3. 分析/proc信息：

cat /proc/[PID]/status | grep -i vm cat /proc/meminfo

实战经验：Java应用建议配合jmap -heap [PID]和MAT工具分析内存快照

4. 磁盘与文件系统故障

4.1 空间不足应急处理

当收到磁盘告警时：

1. 快速定位大文件：

du -ahx / | sort -rh | head -n 20

2. 清理日志文件（示例）：

find /var/log -type f -name "*.log" -mtime +7 -delete journalctl --vacuum-size=200M

3. 特殊文件处理：

• 已删除但未释放的文件：

lsof | grep deleted # 然后重启相关进程

• 磁盘碎片检查（ext4）：

e4defrag -c /dev/sdX

4.2 文件系统修复

当出现文件系统错误时：

1. 只读挂载检查：

mount -o remount,ro /dev/sdX /mnt fsck -y /dev/sdX mount -o remount,rw /dev/sdX /mnt

2. 坏块检测：

badblocks -v /dev/sdX > badblocks.txt

3. 关键目录权限修复：

chmod 755 /bin /usr/bin /sbin /usr/sbin chmod 644 /etc/passwd /etc/group

5. 网络问题深度排查

5.1 连接故障四步法

1. 检查本地配置：

ip a # 查看IP配置 route -n # 路由表 cat /etc/resolv.conf # DNS配置

2. 测试基础连通性：

ping -c4 8.8.8.8 traceroute www.example.com mtr --report www.example.com

3. 验证端口级别连通：

telnet host port nc -zv host port

4. 抓包分析：

tcpdump -i eth0 -w packet.pcap host 10.0.0.1 and port 80 tshark -r packet.pcap -Y "http.request" # 分析HTTP请求

5.2 性能调优技巧

常见网络性能问题处理：

1. TIME_WAIT过多：

sysctl -w net.ipv4.tcp_tw_reuse=1 sysctl -w net.ipv4.tcp_tw_recycle=1 # 慎用

2. 连接数限制：

ss -s # 查看当前连接数 ulimit -n # 检查文件描述符限制

3. 带宽监控：

iftop -i eth0 -n -P nethogs eth0 # 按进程统计流量

6. 系统日志分析实战

6.1 关键日志文件位置

6.2 日志分析三板斧

1. 时间范围筛选：

journalctl --since "2024-03-01 00:00:00" --until "2024-03-02 00:00:00"

2. 关键词过滤：

grep -Ei "error|fail|exception" /var/log/messages

3. 统计排序：

awk '{print $5}' access.log | sort | uniq -c | sort -nr | head -n 10

高级技巧：使用ELK栈或Grafana Loki搭建集中式日志系统

7. 自动化排查工具集

7.1 一键收集诊断信息

创建collect_debug.sh脚本：

#!/bin/bash DEBUG_DIR="/tmp/debug_$(date +%Y%m%d_%H%M%S)" mkdir -p $DEBUG_DIR # 系统信息 uname -a > $DEBUG_DIR/uname.log lscpu > $DEBUG_DIR/cpu.log free -h > $DEBUG_DIR/mem.log df -h > $DEBUG_DIR/disk.log # 进程信息 ps auxf > $DEBUG_DIR/ps.log top -n1 -b > $DEBUG_DIR/top.log # 网络信息 ss -tulnp > $DEBUG_DIR/ss.log ip a > $DEBUG_DIR/ip.log # 关键日志 tail -n 100 /var/log/messages > $DEBUG_DIR/messages.log journalctl -xe --no-pager > $DEBUG_DIR/journal.log tar czf $DEBUG_DIR.tar.gz $DEBUG_DIR echo "诊断包已生成：$DEBUG_DIR.tar.gz"

7.2 常用监控工具推荐

1. 基础监控：

• htop- 增强版top
• glances- 全能监控
• nmon- 性能快照工具

2. 高级诊断：

• strace- 系统调用追踪
• perf- Linux性能分析器
• bpftrace- 动态追踪工具

3. 可视化工具：

• netdata- 实时仪表盘
• Prometheus+Grafana- 监控告警平台

8. 典型故障案例库

8.1 案例1：CPU负载高但使用率低

现象：load average显示15+但%CPU只有30%

排查过程：

1. 检查IO等待：

vmstat 1 5 # 观察wa列 iostat -x 1 # 查看await指标

2. 发现磁盘响应慢：

smartctl -a /dev/sdX # 检查SMART状态

3. 解决方案：

• 更换故障磁盘
• 优化MySQL的innodb_io_capacity参数

8.2 案例2：随机进程被杀死

现象：应用进程不定期消失，日志无异常

排查：

1. 检查内核日志：

dmesg -T | grep -i kill

2. 确认OOM Killer触发：

grep -i oom /var/log/messages

3. 解决方案：

• 调整vm.overcommit_memory参数
• 为关键进程设置oom_score_adj

8.3 案例3：SSH连接缓慢

现象：SSH登录需要10秒以上

排查步骤：

1. 测试连接各阶段耗时：

ssh -vvv user@host 2>&1 | grep "debug1"

2. 发现DNS反查延迟：

grep UseDNS /etc/ssh/sshd_config

3. 解决方案：

echo "UseDNS no" >> /etc/ssh/sshd_config systemctl restart sshd

9. 预防性维护策略

9.1 日常检查清单

建议每天/每周执行的预防性检查：

1. 磁盘空间预测：

df -h | awk '{print $6,$4}' | column -t

2. 内存泄漏检测：

watch -n 3600 'ps aux --sort=-%mem | head -n 10'

3. 定时日志清理：

find /var/log -type f -name "*.log" -size +100M -exec truncate -s 0 {} \;

9.2 性能基准测试

建立系统性能基线：

1. CPU测试：

sysbench cpu --cpu-max-prime=20000 run

2. 磁盘IO测试：

fio --name=randread --ioengine=libaio --rw=randread --bs=4k --numjobs=4 --size=1G --runtime=60 --time_based --group_reporting

3. 网络测试：

iperf3 -c [server_ip] -t 30 -P 8

9.3 应急响应预案

建议每个团队准备：

1. 关键业务恢复流程文档
2. 核心人员联系方式清单
3. 备用系统访问通道（如带外管理）
4. 系统快照/备份验证机制

我习惯在每台服务器上保留一个emergency.txt，包含：

• 关键服务启动顺序
• 必须保护的配置文件路径
• 业务依赖的数据库连接信息

10. 排查工具箱推荐

10.1 命令行工具精选

10.2 图形化工具推荐

1. cockpit- 网页版系统管理面板
2. ksysguard- KDE系统监控器
3. gnome-system-monitor- GNOME系统监视器
4. wireshark- 网络协议分析器
5. sysprof- 系统性能分析器

10.3 自制工具脚本分享

进程资源监控脚本：

#!/bin/bash while true; do clear echo "==== $(date) ====" echo "Top 5 CPU:" ps -eo pid,user,%cpu,cmd --sort=-%cpu | head -n 6 echo echo "Top 5 MEM:" ps -eo pid,user,%mem,cmd --sort=-%mem | head -n 6 echo echo "Disk Usage:" df -h | grep -v tmpfs sleep 5 done

网络连接监控脚本：

#!/bin/bash watch -n 1 'netstat -antp | awk '\''{print $5}'\'' | cut -d: -f1 | sort | uniq -c | sort -nr | head -n 10'

11. 排查思维训练

11.1 五问法追溯根源

对每个故障至少问五次"为什么"：

1. 为什么服务不可用？→ 进程崩溃
2. 为什么进程崩溃？→ 内存不足
3. 为什么内存不足？→ 内存泄漏
4. 为什么有内存泄漏？→ 代码未释放资源
5. 为什么代码有问题？→ 未进行压力测试

11.2 故障模拟演练

建议定期进行故障演练：

1. 内存耗尽：

stress-ng --vm 1 --vm-bytes $(awk '/MemFree/{printf "%d\n", $2 * 0.9;}' < /proc/meminfo)k

2. CPU过载：

stress-ng --cpu $(nproc) --timeout 60s

3. 磁盘写满：

fallocate -l $(df --output=avail / | tail -n1)K /tmp/fill

11.3 复盘文档模板

每个重大故障处理后建议撰写复盘报告，包含：

1. 故障时间线（精确到分钟）
2. 影响范围和程度
3. 根本原因分析（附证据）
4. 应急处理措施
5. 长期改进方案

我维护的故障知识库采用Markdown格式，方便搜索和更新：

## [2024-03-01] MySQL服务OOM故障 ### 现象 - 03:15 监控显示内存使用95% - 03:17 MySQL进程被kill ### 根本原因 未配置内存使用上限，查询缓存膨胀 ### 解决方案 1. 紧急：设置`innodb_buffer_pool_size` 2. 长期：增加监控规则