故障发现后第一分钟应先确认是否真有故障：用uptime和who -b看系统是否刚重启，ping -c 3 127.0.0.1排除网络栈崩溃，ls /proc/1验证init进程是否存在。
故障发现后第一分钟该看什么
别急着重启服务，先确认是否真有故障。用 uptime 和 who -b 看系统是否刚重启过；用 ping -c 3 127.0.0.1 排除网络栈崩溃；用 ls /proc/1 验证 init 进程是否存在——如果连 /proc/1 都打不开，说明内核已严重异常。
常见误判点：
- 监控告警显示“CPU 100%”，但实际是单核忙，
top默认不显示每个核，得按1切换视图 -
df -h显示磁盘满，但可能只是某个挂载点被 overlayfs 或 bind mount 隐藏了真实使用方，得用du -sh /* 2>/dev/null | sort -hr | head -5定位大目录 - SSH 登不进去，未必是 sshd 挂了，可能是
PAM配置错误或/etc/nologin文件存在
快速定位高负载进程的三个命令组合
单靠 top 容易漏掉短时爆发型进程。必须配合 ps 和 pidstat：
- 查最近 10 秒 CPU 占用最高的 5 个进程：
pidstat -u 1 10 | tail -n +4 | sort -k8,8nr | head -5 - 查哪些进程在大量创建线程：
ps -eo pid,tid,pcpu,pmem,lwp,nlwp,comm --sort=-nlwp | head -10（注意nlwp字段） - 查谁在疯狂刷磁盘：
iotop -oP（需 root，-o只显示有 I/O 的进程，-P忽略线程）
注意：pidstat 在低版本 sysstat 中默认不采集磁盘数据，要加 -d 参数才生效；而 iotop 在容器宿主机上可能无法识别容器内进程名，得结合 docker ps --no-trunc 对照 PID。
磁盘空间突增却找不到大文件怎么办
常见原因是被删除但未释放的文件（unlinked but still open）。这类文件不会出现在 du 统计里，但持续占用空间。
执行：lsof +L1 查看所有链接数为 0 的打开文件；再用 lsof -nP +L1 | awk '{print $7,$9}' | sort -nr | head -5 排序出占用最大的几个。
关键细节：
-
+L1是 lsof 的专用参数，不是所有发行版默认支持（CentOS 6 自带 lsof 版本太老，需升级） - 输出中的路径可能是
/var/log/nginx/access.log (deleted)，说明日志轮转后旧文件句柄没关，此时 kill 对应 nginx worker 进程或发kill -USR1重载日志即可释放 - 若看到大量
anon_inode或inotify占用，可能是应用泄漏 inotify 实例，需检查业务代码中inotify_init()是否配对close()
服务端口监听异常的三层排查法
现象：netstat -tlnp 看不到服务端口，但进程明明在跑。问题往往不在应用本身，而在网络命名空间或绑定配置。
- 先确认是否在非默认 netns：
ip netns list，若有，进对应 namespace 查ip netns execss -tlnp - 查进程是否绑定了特定 IP：
ss -tlnp | grep :80，如果只显示127.0.0.1:80而不是*:80，说明应用配置了bind_addr = 127.0.0.1，外部无法访问 - 检查 SELinux 是否拦截：
ausearch -m avc -ts recent | grep port，常见于 CentOS/RHEL 上 httpd 绑定非标准端口时被阻止
一个容易忽略的点：systemd 启动的服务若定义了 PrivateNetwork=yes，即使没显式创建 network namespace，也会隔离网络栈，ss 在 host netns 下自然看不到其监听端口。
