Nginx 监控怎么监控 upstream 后端节点的健康状态与存活率-Nginx-PHP中文网

Nginx不直接提供存活率指标，但可通过nginx_upstream_check_module主动健康检查、/status JSON状态页暴露、Prometheus聚合计算（up节点数/总节点数）实现精准监控与告警。

nginx 监控怎么监控 upstream 后端节点的健康状态与存活率

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 分钟就触发；或某节点 healthcheck_fails_current > 2 就通知值班。

补充建议：让健康检查更贴近业务实际

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

后端 /health 接口应返回结构化 JSON（如 Spring Boot 的 /actuator/health），包含数据库、缓存等依赖项状态；
若需更细粒度控制（比如内存超 95% 就降权），可用 OpenResty + Lua 解析响应体并动态调整权重；
日志中加入 $upstream_addr $upstream_status $upstream_response_time，便于离线分析错误分布和延迟趋势。

不复杂但容易忽略。