需通过nginx_upstream_check_module启用主动健康检查，配合nginx-module-vts或exporter暴露失败次数指标，再由prometheus采集并告警；无模块时可解析错误日志兜底。
要监控 Nginx upstream 健康检查失败次数，核心是让失败行为可采集、可量化、可告警。开源 Nginx 本身不直接暴露“健康检查失败计数”这一指标，必须通过模块扩展 + 指标导出 + Prometheus 抓取三步打通。
启用主动健康检查并暴露原始状态
先确认 Nginx 已编译 nginx_upstream_check_module（运行 nginx -V 2>&1 | grep upstream_check 验证）。在 upstream 块中配置带语义的探测：
check interval=3 rise=2 fall=3 timeout=1 type=http;check_http_send "GET /health HTTP/1.1\r\nHost: api.example.com\r\nConnection: close\r\n\r\n";check_http_expect_alive http_2xx;- 每个
server行加上max_fails=0 fail_timeout=0，禁用被动机制干扰主动探测结果
这样每 3 秒发起一次真实 HTTP 探测，只认 2xx 为健康，失败即计入内部计数器——但该计数器仍不可直接访问。
用 nginx-vts 或 exporter 暴露失败次数指标
推荐使用 nginx-module-vts（比 stub_status 更丰富）或配套的 nginx-vts-exporter：
- 启用 vts 后，访问
/status/format/json可看到每个 upstream 节点的"healthcheck": {"fails": 2, "passes": 5}字段 - 部署
nginx-vts-exporter，它会定期抓取该 JSON 并转换为 Prometheus 格式指标，例如：nginx_upstream_healthcheck_failures_total{upstream="api", server="10.0.1.10:8080"} 2 - 该指标是累计值（counter 类型），适合计算速率和突增
在 Prometheus 中写关键查询与告警
基于导出的指标，可构建以下实用表达式：
- 最近 5 分钟某节点失败速率突增：
rate(nginx_upstream_healthcheck_failures_total{upstream="api", server="10.0.1.10:8080"}[5m]) > 0.2（即平均每 5 秒失败 1 次） - 连续失败未恢复（已触发下线）：
nginx_upstream_healthcheck_failures_total{upstream="api"} > 0 and on(upstream, server) nginx_upstream_healthcheck_status{status="down"} == 1 - 按 upstream 统计当前最高失败次数：
max by (upstream) (nginx_upstream_healthcheck_failures_total)
这些查询可接入 Grafana 看板，也可作为 Alertmanager 的告警规则，附带节点 IP 和最近响应码提升排查效率。
补充：日志方式兜底（无模块时可用）
若无法加模块，可退而求其次解析错误日志：
- 在
http块中开启详细错误日志：error_log /var/log/nginx/upstream_check.log warn; - 配合
nginxlog-exporter或自定义脚本，匹配含"upstream check failed"或探测路径返回非 2xx 的日志行 - 将匹配次数转为 Prometheus counter 指标，精度略低但可应急
不复杂但容易忽略的是：失败次数本身只是信号，真正要告警的是“失败后节点是否还在线”“失败是否集中爆发”“失败是否伴随延迟飙升”，所以建议把失败次数和 nginx_upstream_server_active_connections、nginx_upstream_server_response_time_seconds 一起看。
