Linux 运维高阶命令实战：五大场景故障排查指南

作为运维工程师，只会基础命令只能完成简单的文件操作，真正定位性能瓶颈、分析日志异常、排查网络磁盘故障，靠的是高阶命令的组合运用。本文结合生产实战经验，把运维高频命令按系统监控、日志分析、进程管理、磁盘运维、网络调试五大场景分类，逐条拆解核心用途、常用参数与落地用法，帮助你在服务器负载飙高、日志报错刷屏、磁盘空间爆满、网络链路中断时快速定位问题。

一、系统性能监控与瓶颈定位

top -d 2
top -p 1234
htop
iostat -d -x 1

top 是排查负载过高的第一选择，配合 -p 指定进程、-u 过滤用户；生产环境推荐 htop，支持鼠标操作、树形展示进程父子关系。iostat 用于磁盘 IO 专项分析，%util 持续超过 80% 基本可判定 IO 瓶颈，await 过高代表磁盘处理缓慢。

vmstat 1 5
pidstat -u -r -d 1 5
mpstat -P ALL 1 3
sar -u 1 5

top/htop 解决"是谁在消耗"，vmstat 与 sar 解决"瓶颈在哪一层"：vmstat 1 里 r 列是等待运行的进程数、b 列是阻塞在 IO 的进程数、si/so 反映换页情况、wa 是 IO 等待占比，四个指标组合就能区分 CPU 饱和、IO 瓶颈与内存换页。pidstat 按进程维度采集，比 top 更适合"采集一分钟再分析"。生产服务器建议常开 sysstat 采集（sar -u -f /var/log/sa/sa20），故障发生后回溯历史数据，比现场抓取可靠得多。

二、日志排查与文本智能处理

tail -f app.log
tail -F app.log
grep -C 5 "ERROR" app.log
grep -r "Exception" /var/log/
awk '{print $1}' nginx.access.log
awk '$10>100' nginx.access.log

tail、grep、awk 构成日志分析铁三角：tail -F 适配日志切割场景，grep 的 -C 显示上下文、-r 递归检索，awk 可实现 IP 提取、请求过滤和访问量统计（awk '{count[$1]++} END{for(ip in count) print ip, count[ip]}'）。

sed -n '100,200p' app.log
awk '{print $7}' nginx.access.log | sort | uniq -c | sort -rn | head
grep -oE "\b([0-9]{1,3}\.){3}[0-9]{1,3}\b" app.log | sort | uniq -c | sort -rn | head
zgrep "ERROR" app.log.2026-03-*.gz | tail

日志分析的高频目标其实只有三类，各自有固定套路：定位时间点用 grep 的 -B/-A/-C 取上下文；统计 TOP N（访问最多的 IP、最慢的 URL、出现最多的异常类型）用 awk 提字段再交给 sort/uniq；确认某段区间的变更用 sed 指定行号范围。几个容易被忽略的小参数同样实用：grep -c 只计数、grep -v 反向过滤、zgrep 直接检索 .gz 归档日志。日志文件很大时先用 wc -l 确认规模，再组合 grep --line-buffered 与 tail 流式处理，避免把整个文件读进内存。

三、进程管理与异常恢复

ps -ef | grep java
ps aux
pstree -p

ps 静态快照搭配管道筛选指定服务进程；pstree 以树形展示父子关系，专门排查守护进程异常、子进程僵死、进程启动失败等问题。

pgrep -af java
lsof -p 1234
lsof -i:8080
ls /proc/1234/fd | wc -l
cat /proc/1234/limits

进程排查的顺序通常是"找进程 → 看资源 → 看打开的文件与端口"。pgrep -af 同时输出 PID 与完整命令行，比 ps -ef | grep 更省事且不会误匹配到 grep 自身；lsof -p PID 一次看清进程持有的文件、套接字与共享库，配合 lsof +D /var/log 能找出"正在写日志却删不掉文件"的元凶。要停进程时优先 systemctl stop 服务 或 kill -15，让应用走完清理流程，kill -9 只用于真正无响应的情况。

四、磁盘存储排查与文件管理

df -h
df -i
du -sh /var/log/
find / -size +100M -type f
find /var/log/ -mtime +7 -type f -exec rm -rf {} \;

df -i 解决"磁盘有空间但无法创建文件"的 inode 耗尽问题；du 找出真正占空间的大目录；find 按大小、时间、权限多条件检索，批量清理过期日志。

df -hT; df -i
du -sh /var/* 2>/dev/null | sort -rh | head
lsof | grep deleted | head
find / -xdev -type f -size +1G -exec ls -lh {} \;

磁盘类故障分三种情况：真满了（df 显示 100%）、假满了（df 与 du 结果差异很大，多为已删除但仍被进程占用的文件）、inode 满了（逻辑容量还有余量却无法新建文件）。用 find 批量清理时务必加 -xdev 避免跨越挂载点，删除前先不带 -exec 跑一遍看清楚清单。df -T 同时显示文件系统类型，能快速区分 overlay、xfs、nfs 等不同来源，避免在错误的层级上清理。

五、网络连通性与路由故障调试

ping -c 4 -i 2 192.168.1.1
traceroute www.example.com
mtr www.example.com

ping 验证基础连通性，traceroute 追踪路由节点定位网关位置，mtr 是 ping 与 traceroute 的整合升级版，可实时统计每个节点的丢包率与平均延迟，是生产环境首选。

ss -lntp
ss -s
tcpdump -i eth0 -nn port 80 -c 20
iperf3 -c 10.0.0.20 -t 10 -P 4

网络方向的高阶命令按"由粗到细"排开：ss 看本机监听与连接状态，tcpdump 看实际报文，iperf3 验证带宽上限。判断"是丢包还是延迟"用 mtr，判断"是网络还是服务"用 curl -v --resolve 绕过 DNS，判断"是不是 MTU 问题"用 ping -M do -s 1472。这几条命令组合起来，基本覆盖从链路到应用层的全部推断路径。

六、系统调用与文件句柄追踪

当应用"没有日志、没有报错，但就是卡住"时，需要下沉到系统调用层面看它到底停在哪一步。

strace -p 1234 -T -tt -e trace=network
strace -f -o /tmp/trace.log ./启动脚本
ls -l /proc/1234/fd | tail -5

strace 加 -T 会显示每次系统调用的耗时，-e trace=network 只看网络相关调用，能立刻发现"卡在 connect 或 read"这类问题；-f 跟踪子进程，适合排查 fork 之后行为异常的服务。需要注意的是 strace 会明显降低目标进程性能，生产环境只在低峰或极短时间使用，需要长期观测时改用 bpftrace 等内核追踪工具，开销小得多。

七、先搭性能基线，别等故障才抓数据

sar -u 1 5        # CPU
sar -r 1 5        # 内存
sar -b 1 5        # IO
sar -n DEV 1 5    # 网卡吞吐
pidstat -u -r -d 1 5

排障速度的差距往往不在命令会不会用，而在于"有没有历史数据可以对比"。用 sysstat 每天采集 CPU、内存、IO、网络四类常规值，故障时一眼就能看出哪个指标偏离基线。pidstat 按进程同时输出 CPU、内存与 IO 三个维度，是定位"某个进程偷偷吃资源"最直接的命令。所有指标都正常但业务仍慢时，再上 perf 或 bpftrace 做函数级热点分析。

实战技巧总结

优先选用增强工具（htop 替代 top、mtr 替代 traceroute）；善用管道组合命令实现筛选、排序、统计一站式操作；摒弃死记参数思维，掌握核心场景用法；线上高危操作（find 批量删除、kill 终止进程）务必先查询确认，避免误操作引发生产事故。

更多 Linux 排障内容：mtr 定位丢包与延迟、bpftrace 生产环境一行命令追踪、LVM 精简卷与快照实战、nftables 服务器防火墙配置。

原文链接：https://openeuler.csdn.net/6a101432662f9a54cb765a5a.html