Nginx运维巡检脚本需分四层验证：配置语法（nginx -t）、进程存活（systemctl或pgrep）、端口监听（ss）、服务响应（curl）；模块化函数设计，带超时与容错；异常分级恢复并二次验证；日志闭环管理，cron每3分钟执行。
编写规范的 Nginx 运维巡检与管理脚本，核心是兼顾准确性、可维护性与生产健壮性：不依赖模糊匹配，优先用 systemctl 或 nginx -t 等权威接口验证状态；把检查项拆解为“配置→进程→端口→服务响应”四层逻辑；所有操作留痕、异常可告警、失败有兜底。
明确检查维度与判断依据
Nginx 是否健康不能只看进程是否存在。应分层验证：
-
配置语法正确性：执行
nginx -t，返回码为 0 才算通过。避免配置错误导致 reload 失败却误判为“运行中” -
主进程与工作进程存活：用
systemctl is-active nginx（若已注册为 systemd 服务）或pgrep -f "nginx: master process"+pgrep -f "nginx: worker process" | wc -l验证进程树完整性 -
监听端口就绪：用
ss -tln | grep ':80\b'（或实际监听端口），排除进程在但端口未 bind 的情况 -
服务可达性：执行
curl -s --connect-timeout 3 -o /dev/null -w "%{http_code}" http://127.0.0.1/，HTTP 状态码为 200 才认为对外服务正常
脚本结构需模块化且带容错
一个生产可用的脚本应包含初始化、检查函数、日志记录和异常处理四部分，开头强制声明解释器并启用基础防护：
- 首行写
#!/bin/bash，加set -eo pipefail防止错误被静默忽略 - 定义变量时统一路径：如
NGINX_BIN="/usr/sbin/nginx"、NGINX_CONF="/etc/nginx/nginx.conf"、LOG_FILE="/var/log/nginx/monitor.log" - 每个检查步骤单独封装函数，例如
check_config()、check_port()，失败时记录详细原因（如"nginx -t failed: $(nginx -t 2>&1)"） - 对关键命令加超时保护：如
timeout 5 nginx -t，防止配置文件过大或磁盘卡顿导致脚本挂起
自动恢复与告警要务实有效
发现异常后，不能仅发邮件了事，而应按策略分级响应：
- 配置错误 → 记录日志 + 发送含错误行号的告警（
nginx -t -v可定位具体哪一行）→ 不自动重启（避免覆盖问题配置） - 进程退出但配置正常 → 先尝试
systemctl start nginx；失败则 fallback 到$NGINX_BIN -c $NGINX_CONF - 端口监听失败但进程存在 → 检查是否被其他服务占用（
lsof -i :80），或尝试nginx -s reload - 所有恢复动作执行后，必须再次验证 —— 成功才写 OK 日志，否则标记 “recovery_failed” 并升级告警
日志与调度要可持续
巡检不是一次性动作，需形成闭环：
- 每次执行追加时间戳日志：
echo "$(date '+%F %T') [check] config:$(check_config), port:$(check_port)" >> "$LOG_FILE" - 日志保留 7 天，用
find /var/log/nginx/ -name "monitor.log.*" -mtime +7 -delete定期清理 - 通过 cron 设置合理频次：核心服务建议每 3 分钟一次（
*/3 * * * * /opt/bin/nginx-monitor.sh），避免高频轮询影响性能 - 若服务器无 mail 命令，改用
logger -t nginx-monitor "Alert: service down"写入系统日志，再由 rsyslog 转发至集中平台
