4、故障排查工具链：Linux常用命令（top/df/curl）、网络诊断（ping/telnet/traceroute）、进程管理（ps/systemctl）
做自动化运维这些年，我越来越觉得——工具链就是你的第二双手。故障来了，你慌不慌，就看这双手够不够快。今天咱们就把这套「排查三板斧」掰开揉碎讲清楚。
4.1 系统状态三剑客：top、df、curl
先说 top。这玩意儿我每天至少敲十次。它告诉你CPU谁在吃、内存谁在占、负载高不高。我个人习惯先看 load average 那三个数——如果第三个值（15分钟平均）都超过CPU核数了，那基本可以断定系统已经「喘不过气」了。
关键指标速查：
- %us：用户态CPU占用。太高说明应用在疯狂计算。
- %sy：内核态CPU占用。超过30%要警惕，可能是系统调用太频繁。
- %wa：I/O等待。这个值一高，磁盘大概率是瓶颈。
- RES：常驻内存。比VIRT靠谱，VIRT很多是共享库，虚的。
有一次线上告警说服务响应慢，我上去一看 top，%wa 飙到 60%。我当时就判断是磁盘I/O问题，结果一查，是日志轮转脚本卡住了。嗯，有时候问题就这么直白。
再说 df -h。磁盘满了，服务分分钟挂给你看。我建议你养成习惯：每天巡检先跑一遍 df -h，看看 /、/var、/data 这些关键分区。特别是 /var/log，日志写满磁盘的事故我见过不下十次。
我的小技巧：用 df -i 看inode使用率。有时候磁盘没满，但inode用光了，文件照样写不进去。我曾经被这个坑过——一个临时文件目录里生成了几百万个小文件，df -h 显示还有50%空间，但服务就是报错「磁盘空间不足」。查了半天才发现是inode满了。
最后是 curl。这工具太实用了。我排查HTTP接口问题时，第一反应就是 curl -v 看完整交互过程。你想想看，服务返回500还是502，响应时间是1秒还是10秒，一目了然。
# 常用curl调试参数
curl -v http://localhost:8080/health # 看完整请求响应
curl -I http://example.com # 只看响应头
curl -o /dev/null -s -w '%{http_code}: %{time_total}s\n' http://example.com # 只输出状态码和耗时注意：curl 默认不跟随重定向。如果接口返回301/302，记得加 -L 参数。我见过有人对着302看了半天，以为服务挂了。
4.2 网络诊断三板斧：ping、telnet、traceroute
网络问题排查，说白了就是回答三个问题：通不通？端口开没开？路径对不对？
ping 回答第一个问题。它能告诉你目标主机是否可达，以及网络延迟大概多少。但注意，ping不通不一定是网络问题——有些服务器禁ping。我曾经排查过一个案例，ping不通但业务正常，最后发现是安全组把ICMP给禁了。
telnet 回答第二个问题。它测试的是TCP端口连通性。比如你要确认MySQL的3306端口是否开放：
telnet 192.168.1.100 3306如果出现 Connected to 192.168.1.100，说明端口通了。如果卡住不动或者报 Connection refused，那要么端口没开，要么防火墙拦了。
避坑指南：我曾经用telnet测试Redis端口，发现连不上。查了半天防火墙、安全组都没问题。最后发现——Redis绑定了127.0.0.1，只允许本机访问。所以telnet不通时，先确认服务监听地址对不对。
traceroute 回答第三个问题。它追踪数据包从你机器到目标机器的路径。当网络慢或者丢包时，traceroute能帮你定位是哪个节点出了问题。
traceroute -n www.example.com # -n 参数不解析域名，速度快很多看输出时，重点关注那些 * * * 或者延迟突然飙升的跳点。如果某个中间节点连续丢包，那问题大概率出在那一段。
4.3 进程管理：ps 与 systemctl
进程管理这块，ps 和 systemctl 是我最常用的两个命令。一个管「活的进程」，一个管「服务状态」。
ps aux 是我排查进程问题的起手式。它能列出所有进程的CPU、内存、启动时间等信息。我一般会配合 grep 过滤：
ps aux | grep java # 找Java进程
ps aux --sort=-%cpu | head # 看CPU占用最高的10个进程
ps aux --sort=-%mem | head # 看内存占用最高的10个进程有一次服务莫名其妙重启了，我查了半天日志没找到原因。后来用 ps -eo pid,lstart,cmd | grep myapp 看进程启动时间，发现凌晨3点重启过一次。再配合 journalctl 一查，是OOM Killer把进程干掉了。嗯，内存泄漏。
实用技巧：想看进程的父子关系？用 ps -ef --forest。它会以树形结构展示进程，一眼就能看出谁是谁的子进程。排查僵尸进程时特别好用。
systemctl 是管理systemd服务的标准工具。我建议你记住这几个常用操作：
| 命令 | 作用 |
|---|---|
| systemctl status xxx | 查看服务状态（最常用） |
| systemctl restart xxx | 重启服务 |
| systemctl enable xxx | 设置开机自启 |
| systemctl list-units --type=service | 列出所有服务 |
| journalctl -u xxx | 查看服务的日志（配合排查利器） |
注意：systemctl status 显示的是服务当前状态，但有时候服务进程还在跑，systemctl却显示 inactive。为什么？因为服务可能不是通过systemd启动的。我遇到过有人手动执行了启动脚本，systemctl 当然不认。所以排查时，ps 和 systemctl 要结合着看。
好了，这套工具链你掌握了，大部分故障都能快速定位。说白了，排查就像破案——工具是放大镜，经验才是关键。多练，多踩坑，你也能成为那个「看一眼就知道问题在哪」的人。