Linux系统故障排查：从基础命令到高阶技巧-尧图网络科技

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.panic=10可设置自动重启时间
系统服务故障
- 典型表现：服务启动超时、端口占用、依赖缺失
- 诊断工具：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`、`pidstat`	CPU异常占用	`pidstat -urd -p PID 1 5`
磁盘I/O	`iotop`、`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,logbsize=256k
升级内核到4.19+版本修复已知bug

4.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 'NR>1 {if ($5 > 85) print $0}' } check_oom() { dmesg -T | grep -i "out of memory" } # 执行所有检查 check_load check_disk check_oom