线上问题排查流程：日志、端口、进程、磁盘、网络怎么一步步看

线上出问题时，最怕一上来就乱改配置。我的习惯是先确认现象，再按日志、端口、进程、磁盘、网络、容器这个顺序看。

先确认问题边界

先问几个问题：

• 是所有用户都不行，还是部分用户不行
• 是接口慢，还是完全打不开
• 是刚发布后出问题，还是自然发生
• 是单台机器，还是多台机器

不要跳过这一步。它决定后面查应用、网络还是资源。

看服务状态和日志

如果是 systemd 管理：

1
systemctl status app
2
journalctl -u app -n 200 --no-pager

如果是 Docker：

1
docker compose ps
2
docker compose logs --tail=200 web

Docker 日志排查可以参考 Docker 日志和排障：logs、exec、inspect、stats。

看端口是否监听

1
ss -lntp

重点看服务端口是否在监听，监听地址是 127.0.0.1 还是 0.0.0.0。如果 Nginx 转发到 127.0.0.1:8000，但应用实际没监听，通常就是 502。

网络命令可以接着看 Linux 网络排查命令：ss、curl、dig、ping、traceroute。

看进程和资源

1
ps aux --sort=-%cpu | head
2
free -h
3
df -h

磁盘满会引发很多奇怪问题：日志写不进去、数据库无法写入、临时文件创建失败。

进程排查可以参考 Linux 进程查看与管理：ps、top、htop、kill、jobs。

看应用健康接口

如果服务有健康检查：

1
curl -i http://127.0.0.1:8000/health

再从 Nginx 外层访问：

1
curl -i http://127.0.0.1/health

两次结果不同，说明问题可能在代理层。

看最近改动

很多线上事故和最近改动有关：

• 刚发布的新镜像
• 刚执行的数据库迁移
• 刚改的 Nginx 配置
• 证书刚续期
• 环境变量刚调整

有 Git 或部署日志时，先把最近一次变更找出来。

一条实用原则

先收集证据，再做改动。每次只改一个点，改完马上验证。

总结

如果是临时恢复，也要记录你改了什么。否则服务虽然恢复了，下一次部署可能又把问题带回来。排障的重点不是记住所有命令，而是保持顺序：先确认现象，再收集证据，最后小步修改。

服务器基础安全也会影响排障边界。新机器上线前建议先看 Linux 服务器安全基础：SSH、用户权限、防火墙和 fail2ban，避免把暴露端口、弱登录和权限问题混在业务故障里。