Nginx集群高可用需构建分层监控体系：指标（Prometheus采集）、日志（结构化JSON+ES分析）、追踪（X-Request-ID链路串联）三支柱协同；健康检查须穿透至业务语义层，节点探活需覆盖Worker卡死等场景；告警分级联动，避免重复并匹配修复能力。
要让 Nginx 集群真正“高可用”，光靠多台机器和负载均衡远远不够——关键在于构建一套能及时发现异常、准确定位问题、自动响应干预的应用监控体系。这套体系不是堆工具，而是分层协同：从 Nginx 自身状态、上游服务健康、集群节点存活，到请求链路质量，每一层都要有可观测性和反馈闭环。
可观测性三支柱：指标、日志、追踪
单一维度的监控容易漏判。比如只看 CPU 使用率正常，但 Nginx Worker 可能全部卡在上游超时；只查进程存在，却无法感知 HTTP 层已无响应。
- 指标（Metrics）：接入 Prometheus，通过 nginx-vts-module 或 OpenResty 的 lua-resty-prometheus 插件采集实时连接数、请求速率、5xx/4xx 比例、upstream 响应时间 P95/P99、失败重试次数等核心指标；重点设置告警阈值，如 5xx 率 > 1% 持续 2 分钟、upstream 超时率突增 300%
- 日志（Logs）：启用结构化 access_log（如 JSON 格式），记录 $status、$upstream_status、$upstream_response_time、$request_time、$http_x_request_id；用 Filebeat 或 Fluent Bit 统一收集至 Elasticsearch，支持按错误码、后端 IP、URL 路径快速下钻分析
- 追踪（Tracing）：在 Nginx 中注入 X-Request-ID（或使用 OpenResty + Zipkin/Jaeger 插件），串联用户请求从入口到后端服务的完整链路；当某类请求延迟飙升时，可直接定位是 Nginx 转发慢、还是某个 upstream 节点响应拖慢、或是下游服务瓶颈
健康检查必须穿透到业务语义层
Nginx 的 max_fails/fail_timeout 只能判断 TCP 连通性，无法识别应用级“假活”——进程在、端口通、但 /health 返回 503 或响应超时 10 秒。
- 所有后端服务必须暴露标准就绪探针（如 /actuator/health 或 /healthz），返回 HTTP 200 且 body 含 "status":"UP"；禁止复用业务接口做健康检查
- 在 upstream 块中配合第三方模块（如 nginx_upstream_check_module）或自定义 location + proxy_pass 实现主动 HTTP 探活，间隔 ≤ 5 秒，超时 ≤ 2 秒，失败连续 2 次即摘除节点
- 对关键业务路径（如支付回调、登录鉴权）配置独立 health check 路由，避免因非核心服务异常导致误切流量
集群节点自身高可用不能只靠 Keepalived
VIP 漂移解决的是“Nginx 进程挂了”的场景，但更常见的是：Master 进程存活、Worker 全部卡死、配置 reload 失败、文件描述符耗尽、SSL 证书过期——这些 Keepalived 无法感知。
- 每个 Nginx 节点部署轻量级探活脚本，每 10 秒执行 curl -I http://127.0.0.1/healthz -o /dev/null -s -w "%{http_code}"；返回非 200 则触发本地重启或降权
- 将 nginx -t 加入 reload 流程前置校验，CI/CD 发布时自动验证配置语法；生产环境 reload 命令封装为带 rollback 的原子操作
- 用 systemd 管理 Nginx 服务，配置 Restart=always、RestartSec=5、OOMScoreAdjust=-100，确保 Master 进程不被 OOM 杀掉
告警与响应需分级联动
告警不是越多越好，而是要匹配运维节奏和修复能力。同一故障不应在多个层级重复告警，而应形成递进式响应。
- 一级告警（立即响应）：VIP 漂移事件、5xx 率 > 5%、核心 upstream 全部不可用 → 触发短信+电话，自动执行流量切换预案
- 二级告警（人工介入）：单个 upstream 节点反复进出健康池、平均响应时间翻倍、SSL 证书剩余有效期
- 三级告警（趋势预警）：连接数持续增长逼近 limit_conn、磁盘 usage > 85%、日志 ERROR 行数环比增 200% → 邮件汇总，纳入每日巡检清单
