1. Linux系统故障排查的核心价值在运维工程师的日常工作中系统故障就像不请自来的访客。我至今记得第一次面对生产环境服务器宕机时的手足无措——那是个凌晨三点监控警报疯狂闪烁而我对着一片空白的屏幕大脑同样空白。正是这些实战教训让我意识到系统的故障排查能力才是工程师真正的救命稻草。不同于Windows系统的图形化排错Linux系统要求我们掌握更底层的诊断思维。这就像医生问诊发烧是表象真正的病因可能藏在系统日志、进程状态或硬件指标中。本文将分享我十年运维生涯中总结的故障排查方法论涵盖从基础命令到高阶技巧的全套解决方案。2. 故障分类与诊断路径2.1 五大核心故障类型根据故障影响范围我将其归纳为五个层级硬件层故障典型表现硬盘SMART告警、内存ECC错误、CPU过热降频诊断工具smartctl、dmidecode、ipmitool服务器案例某次数据库服务器频繁崩溃最终通过edac-util发现是内存条插槽氧化导致内核层故障典型表现OOM Killer日志、内核panic、模块加载失败诊断工具dmesg -T、journalctl -k、/proc/kmsg关键技巧sysctl -w kernel.panic10可设置自动重启时间系统服务故障典型表现服务启动超时、端口占用、依赖缺失诊断工具systemctl status --full、ss -tulnp、strace避坑指南注意systemd的DefaultTimeoutStartSec参数网络连接故障典型表现DNS解析失败、路由异常、连接重置诊断工具mtr、tcpdump、conntrack -L实战经验ethtool -S eth0查看网卡丢包统计应用层故障典型表现进程僵死、日志报错、性能劣化诊断工具jstack、gdb、perf top典型场景Java应用的OutOfMemoryError需配合-XX:HeapDumpOnOutOfMemoryError参数2.2 黄金排查法则我总结的四象限诊断法可见性先确认故障现象是否可稳定复现隔离性通过最小化测试环境排除干扰因素追溯性根据时间线分析变更记录/var/log/apt/history.log可观测性建立监控基线如netdata的指标对比3. 核心诊断工具详解3.1 系统状态三件套# 综合状态快照适合快速检查 $ uptime free -h df -h mpstat -P ALL ss -s # 输出示例 18:30:01 up 45 days, 7:32, 1 user, load average: 1.25, 0.98, 0.75 total used free shared buff/cache available Mem: 62Gi 5.2Gi 54Gi 1.2Gi 2.8Gi 55Gi /dev/nvme0n1p2 98Gi 24Gi 69Gi 12Gi CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle all 5.21 0.00 1.34 0.12 0.00 0.05 0.00 0.00 0.00 93.28 Total: 1283 (kernel 1499) TCP: 85 (estab 42, closed 25, orphaned 0, timewait 25)关键指标解读load average 0.7*CPU核心数需警惕%iowait持续高于5%说明存储瓶颈available内存才是真实可用值3.2 高级诊断工具链工具类别经典工具适用场景关键参数进程分析htop、pidstatCPU异常占用pidstat -urd -p PID 1 5磁盘I/Oiotop、blktrace存储延迟高iotop -oPa网络流量iftop、nethogs带宽异常iftop -nNP内核追踪perf、bpftrace性能热点分析perf record -ag -- sleep 10日志聚合lnav、grep -C 50多日志关联分析journalctl --since 1 hour ago特别提示在生产环境使用strace需谨慎可能引发性能雪崩。建议先通过perf定位大致范围。4. 经典故障场景实战4.1 案例一CPU爆满排查现象某台Web服务器CPU持续100%但top显示无高负载进程排查过程确认无僵尸进程ps -A -ostat,ppid | grep -e [zZ]检查内核线程ps -eLf | grep -v 0 0发现kworker异常使用perf采样perf record -g -a sleep 60 perf report --no-children发现xfs文件系统日志线程频繁唤醒解决方案调整文件系统mount参数rw,noatime,nodiratime,logbsize256k升级内核到4.19版本修复已知bug4.2 案例二磁盘空间神秘消失现象df显示磁盘已用90%但du -sh /统计只有60%排查步骤检查已删除未释放文件lsof L1查找大文件ncdu -x /发现Docker容器日志未轮转ls -lh /var/lib/docker/containers/*/*-json.log配置/etc/docker/daemon.json{ log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 } }5. 预防性运维体系5.1 监控指标基线化建议部署以下监控组合基础指标node_exporter Prometheus日志分析Loki Grafana网络拓扑Smokeping业务指标自定义exporter关键报警阈值设置CPU负载15分钟均值核心数*2内存可用内存10%磁盘inode使用率85%5.2 自动化排查脚本分享我的快速检查脚本healthcheck.sh#!/bin/bash RED\033[0;31m GREEN\033[0;32m NC\033[0m check_load() { local load$(awk {print $1} /proc/loadavg) local cores$(nproc) if (( $(echo $load $cores * 0.7 | bc -l) )); then echo -e ${RED}High load: $load${NC} ps -eo pid,ppid,cmd,%mem,%cpu --sort-%cpu | head -n 10 else echo -e ${GREEN}Load OK: $load${NC} fi } check_disk() { df -h | awk NR1 {if ($5 85) print $0} } check_oom() { dmesg -T | grep -i out of memory } # 执行所有检查 check_load check_disk check_oom6. 排查工具箱推荐6.1 终端神器组合实时监控glances替代top日志分析lnav支持SQL查询日志网络诊断mtr结合pingtraceroute压测工具stress-ng模拟各类负载6.2 图形化工具性能分析sysstat套装中的isag火焰图生成FlameGraph工具链容器诊断ctop容器版top7. 排查思维培养最后分享三点心得保持怀疑第三方监控数据也可能出错总要亲自验证时间线思维任何故障都有前兆/var/log是你的时间机器最小化验证用busybox容器构建最简测试环境记住优秀的运维工程师不是不会遇到问题而是能比别人更快定位到/proc/[pid]/root下的真相。每次故障都是提升的机会关键是要形成自己的排查checklist。
