Linux系统问题定位方法_从现象到根因解析【教程】_网络技术

Linux故障应按资源层→服务层→日志层→网络权限层→系统层级链排查：先用top/htop、free、df、iostat查CPU、内存、磁盘、I/O；再用systemctl、journalctl、ss定位服务与端口；结合dmesg、SELinux、防火墙、权限及strace深入验证。

Linux系统出问题时，别急着重装或重启，大部分故障能通过分层排查快速定位。关键不是“看啥命令”，而是“按什么顺序看”。

很多看似奇怪的行为（如命令卡住、SSH连不上、服务响应慢）其实只是内存或CPU被占满。优先确认基础资源水位，避免在错误方向上浪费时间。

top 或 htop 看实时 CPU 和内存占用，注意 %CPU 和 RES 列；htop 更直观，但需手动安装
free -h 检查 available 是否接近 0；若 available 极低但 cached 很高，可能是内核缓存未及时回收，不一定是真实内存不足
df -h 查磁盘空间，重点看 /、/var、/tmp —— 日志打爆 /var 是高频原因
iostat -x 1（需 sysstat 包）看 %util 和 await，持续 >90% 或 await >100ms 表明 I/O 瓶颈

服务不可用，往往不是它自己崩了，而是上游依赖挂了，比如数据库连不上导致 Web 服务报 502，或者 systemd 里某个单元 failed 导致连锁失败。

systemctl list-units --state=failed 直接列出所有失败单元，比翻日志快得多
systemctl status service-name 看该服务的最新日志、启动状态、依赖关系（Loaded: 行会显示 unit 文件路径，可确认是否被覆盖或修改）
journalctl -u service-name -n 50 --no-pager 查最近 50 行日志；加 -b 可限定当前 boot，避免翻到上次关机前的旧记录
对网络服务，用 ss -tulnp | grep port 确认端口是否真被监听，且是预期进程在监听（ss 比 netstat 更轻量、更准）

直接 tail -f /var/log/messages 容易漏掉关键上下文，也容易被滚动日志冲走。得用时间、关键词、优先级三重锚定。

journalctl --since "2025-06-15 14:30:00" --until "2025-06-15 14:35:00" 锁定故障发生窗口
journalctl -p err..alert 只看错误及以上级别；-p warning 可补看预警信息
dmesg -T | grep -i "oom\|kill\|fail\|error" 查内核级事件，OOM killer 日志就在这里，Out of memory: Kill process 后面跟着的就是被干掉的进程
应用日志路径不统一？先查 systemctl show -p FragmentPath service-name 看 unit 文件在哪，里面常有 StandardOutput 或 LogPath 提示

网络不通、拒绝连接、Permission denied 这类报错，表面看是配置问题，实际常因 SELinux、防火墙策略或文件权限链断裂引发。

getenforce 看 SELinux 是否启用；若为 Enforcing，临时 setenforce 0 测试是否恢复——若恢复，说明是 SELinux 策略限制，而非配置本身错
firewall-cmd --list-all（firewalld）或 iptables -L -n -v（iptables）确认端口是否放行；注意 public zone 默认可能没开你用的端口
权限问题先跑 ls -lZ（含 SELinux 上下文）和 ls -ld（父目录权限），常见坑：Web 服务进程用户无法 traverse 上级目录（即缺少执行 x 权限）
strace -p pid -e trace=openat,connect,bind 实时抓进程在打开哪些文件、连哪个地址——比猜配置文件路径高效得多

journalctl -u nginx --since "2025-06-15 10:00:00" -p err | grep -E "(connect|permission|denied|failed)"

真正难的不是命令记不住，而是看到一条报错后，不知道该往系统哪一层挖：是硬件层（磁盘坏块）、内核层（OOM、模块异常）、运行时层（cgroup 限流、OOMScoreAdj 设置）、还是应用层（配置错、代码 bug）。每次排查，都得默念一遍这个层级链。