1. Linux故障排查作战地图深夜告警的终极解决方案凌晨三点刺耳的告警声划破夜空。服务器CPU飙红、磁盘爆满、网络中断...作为运维工程师这种场景你一定不陌生。面对复杂的Linux系统故障慌乱地敲着各种命令却找不到问题根源这份作战地图就是为你准备的。我整理了15年运维实战中总结的Linux故障排查方法论将零散的命令和检查点组织成清晰的排查路径。不同于网上零碎的教程这是一套完整的应急响应流程从告警现象直达问题根源就像军事地图一样指引你快速定位战场关键点。2. 核心排查框架设计2.1 四层诊断模型所有Linux故障都可以归类到以下四个层面硬件层CPU/内存/磁盘/网络设备等物理问题系统层内核、服务进程、资源限制等应用层具体业务程序的异常网络层连接、防火墙、DNS等排查时建议按照自底向上的顺序先排除底层问题再检查上层应用。这就像医生诊断病人先检查生命体征再分析具体症状。2.2 黄金五分钟检查清单接到告警后的前五分钟最为关键建议按此顺序快速收集信息检查项命令/方法关键指标系统负载uptimetop -n1 -b1/5/15分钟负载CPU使用率内存状态free -hvmstat 1 5可用内存swap使用情况磁盘空间df -hdu -sh /*各分区使用率网络连接ss -tulnpping端口监听基本连通性关键进程ps auxfsystemctl list-units服务运行状态提示将这些命令保存为check.sh脚本赋予执行权限后一键运行3. 深度诊断工具与技术3.1 CPU问题排查实战当top显示CPU使用率过高时定位热点进程ps -eo pid,user,%cpu,%mem,cmd --sort-%cpu | head -n 10分析具体线程top -H -p [PID] pidstat -t -p [PID] 1 5性能采样适合Java应用jstack [PID] thread_dump.log perf top -p [PID]常见问题用户态CPU高通常是业务代码问题检查热点函数系统态CPU高可能是系统调用频繁或IO等待僵尸进程检查父进程是否正确处理SIGCHLD3.2 内存泄漏定位技巧内存问题的典型表现free显示可用内存持续下降开始使用swap空间OOM Killer频繁触发排查步骤监控内存变化趋势watch -n 1 free -h; echo; ps aux --sort-%mem | head -n 5检测内存泄漏工具valgrind --leak-checkfull ./your_program pmap -x [PID] # 查看内存映射分析/proc信息cat /proc/[PID]/status | grep -i vm cat /proc/meminfo实战经验Java应用建议配合jmap -heap [PID]和MAT工具分析内存快照4. 磁盘与文件系统故障4.1 空间不足应急处理当收到磁盘告警时快速定位大文件du -ahx / | sort -rh | head -n 20清理日志文件示例find /var/log -type f -name *.log -mtime 7 -delete journalctl --vacuum-size200M特殊文件处理已删除但未释放的文件lsof | grep deleted # 然后重启相关进程磁盘碎片检查ext4e4defrag -c /dev/sdX4.2 文件系统修复当出现文件系统错误时只读挂载检查mount -o remount,ro /dev/sdX /mnt fsck -y /dev/sdX mount -o remount,rw /dev/sdX /mnt坏块检测badblocks -v /dev/sdX badblocks.txt关键目录权限修复chmod 755 /bin /usr/bin /sbin /usr/sbin chmod 644 /etc/passwd /etc/group5. 网络问题深度排查5.1 连接故障四步法检查本地配置ip a # 查看IP配置 route -n # 路由表 cat /etc/resolv.conf # DNS配置测试基础连通性ping -c4 8.8.8.8 traceroute www.example.com mtr --report www.example.com验证端口级别连通telnet host port nc -zv host port抓包分析tcpdump -i eth0 -w packet.pcap host 10.0.0.1 and port 80 tshark -r packet.pcap -Y http.request # 分析HTTP请求5.2 性能调优技巧常见网络性能问题处理TIME_WAIT过多sysctl -w net.ipv4.tcp_tw_reuse1 sysctl -w net.ipv4.tcp_tw_recycle1 # 慎用连接数限制ss -s # 查看当前连接数 ulimit -n # 检查文件描述符限制带宽监控iftop -i eth0 -n -P nethogs eth0 # 按进程统计流量6. 系统日志分析实战6.1 关键日志文件位置日志类型路径分析工具系统消息/var/log/messagesgrep, awk认证日志/var/log/securelast, lastb内核日志/var/log/kern.logdmesg服务日志/var/log/[service]/journalctl -u [service]启动日志/var/log/boot.logless6.2 日志分析三板斧时间范围筛选journalctl --since 2024-03-01 00:00:00 --until 2024-03-02 00:00:00关键词过滤grep -Ei error|fail|exception /var/log/messages统计排序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.gz7.2 常用监控工具推荐基础监控htop- 增强版topglances- 全能监控nmon- 性能快照工具高级诊断strace- 系统调用追踪perf- Linux性能分析器bpftrace- 动态追踪工具可视化工具netdata- 实时仪表盘PrometheusGrafana- 监控告警平台8. 典型故障案例库8.1 案例1CPU负载高但使用率低现象load average显示15但%CPU只有30%排查过程检查IO等待vmstat 1 5 # 观察wa列 iostat -x 1 # 查看await指标发现磁盘响应慢smartctl -a /dev/sdX # 检查SMART状态解决方案更换故障磁盘优化MySQL的innodb_io_capacity参数8.2 案例2随机进程被杀死现象应用进程不定期消失日志无异常排查检查内核日志dmesg -T | grep -i kill确认OOM Killer触发grep -i oom /var/log/messages解决方案调整vm.overcommit_memory参数为关键进程设置oom_score_adj8.3 案例3SSH连接缓慢现象SSH登录需要10秒以上排查步骤测试连接各阶段耗时ssh -vvv userhost 21 | grep debug1发现DNS反查延迟grep UseDNS /etc/ssh/sshd_config解决方案echo UseDNS no /etc/ssh/sshd_config systemctl restart sshd9. 预防性维护策略9.1 日常检查清单建议每天/每周执行的预防性检查磁盘空间预测df -h | awk {print $6,$4} | column -t内存泄漏检测watch -n 3600 ps aux --sort-%mem | head -n 10定时日志清理find /var/log -type f -name *.log -size 100M -exec truncate -s 0 {} \;9.2 性能基准测试建立系统性能基线CPU测试sysbench cpu --cpu-max-prime20000 run磁盘IO测试fio --namerandread --ioenginelibaio --rwrandread --bs4k --numjobs4 --size1G --runtime60 --time_based --group_reporting网络测试iperf3 -c [server_ip] -t 30 -P 89.3 应急响应预案建议每个团队准备关键业务恢复流程文档核心人员联系方式清单备用系统访问通道如带外管理系统快照/备份验证机制我习惯在每台服务器上保留一个emergency.txt包含关键服务启动顺序必须保护的配置文件路径业务依赖的数据库连接信息10. 排查工具箱推荐10.1 命令行工具精选工具类别推荐工具适用场景系统监控htop, glances, nmon实时系统状态查看网络分析tcpdump, wireshark, mtr网络包捕获与分析性能诊断perf, strace, bpftrace深度性能剖析日志处理jq, logrotate, multilog日志解析与维护文件处理ripgrep, fd, fzf高效文件搜索10.2 图形化工具推荐cockpit- 网页版系统管理面板ksysguard- KDE系统监控器gnome-system-monitor- GNOME系统监视器wireshark- 网络协议分析器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 1011. 排查思维训练11.1 五问法追溯根源对每个故障至少问五次为什么为什么服务不可用→ 进程崩溃为什么进程崩溃→ 内存不足为什么内存不足→ 内存泄漏为什么有内存泄漏→ 代码未释放资源为什么代码有问题→ 未进行压力测试11.2 故障模拟演练建议定期进行故障演练内存耗尽stress-ng --vm 1 --vm-bytes $(awk /MemFree/{printf %d\n, $2 * 0.9;} /proc/meminfo)kCPU过载stress-ng --cpu $(nproc) --timeout 60s磁盘写满fallocate -l $(df --outputavail / | tail -n1)K /tmp/fill11.3 复盘文档模板每个重大故障处理后建议撰写复盘报告包含故障时间线精确到分钟影响范围和程度根本原因分析附证据应急处理措施长期改进方案我维护的故障知识库采用Markdown格式方便搜索和更新## [2024-03-01] MySQL服务OOM故障 ### 现象 - 03:15 监控显示内存使用95% - 03:17 MySQL进程被kill ### 根本原因 未配置内存使用上限查询缓存膨胀 ### 解决方案 1. 紧急设置innodb_buffer_pool_size 2. 长期增加监控规则