Nginx不直接提供存活率指标，但可通过nginx_upstream_check_module主动健康检查、/status JSON状态页暴露、Prometheus聚合计算（up节点数/总节点数）实现精准监控与告警。
Nginx 本身不直接计算或暴露“存活率”这个百分比指标，但可以通过主动健康检查 + 状态页暴露 + 简单聚合，实时掌握每个 upstream 节点是否在线、何时异常、连续失败次数等关键信息，从而准确判断集群整体健康水位。
用 nginx_upstream_check_module 做真实业务级探测
被动靠 max_fails 触发下线太滞后，必须主动发请求验证后端真实服务能力：
- 在
upstream块中启用探测，例如：upstream api_backend { server 10.0.1.10:8080; server 10.0.1.11:8080; check interval=5 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; default_down on; } -
rise=2 fall=3防网络抖动误判；http_2xx是硬性要求——返回 503、404 或{"status":"DOWN"}的节点一律视为不健康； -
default_down on避免 Nginx 启动时把未就绪节点当健康节点转发流量。
配置可读的状态页，一眼看清节点状态
光探测不行，得把结果结构化输出，方便人看或程序解析：
- 添加受保护的 status 接口：
location /status { check_status json; allow 10.0.1.0/24; deny all; } - 访问
/status返回 JSON，含每个节点的ip、port、status（up/down）、rise/fall计数、last_check_time、response_code等字段； - 不建议用 HTML 格式，JSON 更易被脚本或 Prometheus 拉取；务必限制访问来源，避免泄露后端拓扑。
用 Prometheus 计算存活率并告警
存活率本质是“当前标记为 up 的节点数 ÷ 总节点数”，可通过 exporter 自动聚合：
- 使用
nginx-vts-exporter或nginx-upstream-check-exporter抓取/status数据； - 在 Prometheus 中写 PromQL：
count by (upstream) (nginx_upstream_healthcheck_status{status="up"} == 1) / count by (upstream) (nginx_upstream_healthcheck_status) - 设定告警规则，例如：
存活率 持续 2 分钟就触发；或某节点 <code>healthcheck_fails_current > 2就通知值班。
补充建议：让健康检查更贴近业务实际
- 后端
/health接口应返回结构化 JSON（如 Spring Boot 的/actuator/health），包含数据库、缓存等依赖项状态； - 若需更细粒度控制（比如内存超 95% 就降权），可用 OpenResty + Lua 解析响应体并动态调整权重；
- 日志中加入
$upstream_addr $upstream_status $upstream_response_time，便于离线分析错误分布和延迟趋势。
不复杂但容易忽略。
