Linux 故障应急处理流程设计

故障发现后第一分钟应先确认是否真有故障：用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 exec ss -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 下自然看不到其监听端口。