prometheus告警可驱动nginx故障转移闭环，需结合细粒度指标（5xx率、p95延迟、后端状态）生成带upstream/action/target的精准告警，通过alertmanager webhook调用脚本热重载配置，并内置日志、限频、回滚与安全防护机制。
单纯靠Prometheus告警不能直接触发Nginx故障转移，但可以作为自动化决策的“大脑”，联动脚本或配置热重载实现闭环。关键在于把告警事件转化为可执行动作，而不是只发邮件。
告警必须精准反映后端真实健康状态
基础的 Nginx upstream 健康检查（如 max_fails/fail_timeout）只能感知连接级失败，容易漏判响应慢、5xx率高、超时但未断连等“亚健康”状态。Prometheus 的价值在于用细粒度指标补全这个盲区：
- 用
nginx_http_requests_total{status=~"5.."} / nginx_http_requests_total计算 5xx 错误率，持续超 5% 触发 warning 级告警 - 用
nginx_http_request_duration_seconds_bucket{le="2.0",upstream="api"}统计 P95 延迟，超过阈值（如 1.5 秒）且持续 3 分钟，触发 critical 告警 - 结合
nginx_upstream_server_state（来自 OpenResty + lua-resty-prometheus）或自定义探针暴露的后端存活状态，比被动等待连接失败更主动
Alertmanager 告警需携带可操作上下文
默认告警只含 labels 和 annotations，但自动化需要明确“对谁、做什么”。在 Alertmanager 的告警规则中，必须注入关键字段：
-
labels: {upstream: "payment", instance: "nginx-prod-01"}—— 指明受影响 upstream 名称和 Nginx 实例 -
annotations: {action: "degrade", target: "payment-v1"}—— 明确指令类型（降级/剔除/切流）和目标后端 - 避免泛化告警，例如不写
severity: critical而不带 target，否则脚本无法判断该操作哪组 upstream
用 Webhook 接收告警并执行配置变更
Alertmanager 支持 Webhook 接口，这是打通告警与执行的关键桥梁。典型流程是：
- Alertmanager 将匹配到的告警 POST 到一个轻量服务（如 Python Flask 或 Go HTTP server）
- 该服务解析 payload 中的
upstream和action，生成新的 Nginx upstream 配置片段（例如注释掉server payment-v1.example.com;） - 调用
nginx -t && nginx -s reload热重载，整个过程秒级完成，无需重启进程 - 可选：重载前先通过
curl -s http://localhost/nginx_status校验当前 active connections，避开业务高峰时段
安全与回滚机制不能省略
自动修改线上配置风险极高，必须内置防护：
- 所有变更操作记录完整日志，包含告警 ID、时间、变更前/后配置 diff
- 设置静默窗口：同一 upstream 在 10 分钟内只允许一次降级操作，防止单点抖动引发反复切换
- 配置自动回滚：若新配置 reload 后 30 秒内出现
nginx: [emerg]错误，立即恢复上一版配置并 reload - Webhook 服务本身需加 basic auth 或 IP 白名单，防止恶意调用
这套机制不是替代 Nginx 原生健康检查，而是叠加一层基于业务指标的智能判断层。它让故障转移从“连接不通才切”变成“响应变慢就切”，真正贴近用户体验。
