需借助nginx-module-vts或upstream_check_module暴露per-server活跃连接数、响应延迟等指标，并通过nginx-prometheus-exporter解析json状态页，生成如nginx_upstream_server_active_connections{upstream="api",server="192.168.1.10:8000"}等结构化指标供prometheus采集与告警。
要监控 Nginx Upstream 节点的实时负载详情，核心在于获取每个后端节点的活跃连接数、请求速率、响应延迟和健康状态，并将这些指标结构化暴露给 Prometheus。Nginx 原生不直接提供 per-server 的实时连接数或健康分，必须借助扩展模块与 exporter 协同完成。
启用 upstream 粒度的状态采集能力
Nginx 默认的 stub_status 仅暴露全局连接统计（如 Active connections），无法下钻到单个 upstream server。需引入以下任一机制：
- 使用
nginx-module-vts：支持 JSON/HTML 格式输出各 upstream 的请求数、字节数、响应时间、当前活跃连接数（active字段）等，地址形如/status?format=json - 启用
upstream_check_module（如淘宝版）：在upstream块中配置check指令后，该模块会提供/status?format=json接口，返回每个 server 的rise、fall、status及active连接数 - OpenResty 用户可结合
lua-resty-healthcheck或自定义 Lua handler 动态上报指标
部署 nginx-prometheus-exporter 并正确对接
官方 nginx-prometheus-exporter 支持解析 vts 和 upstream_check 提供的 JSON 状态页，但需明确配置：
- 确保 exporter 启动时指定对应端点，例如：
--nginx.scrape-uri=http://127.0.0.1:8080/status?format=json - 若使用
upstream_check_module，确认其 JSON 输出中包含upstreamZones和每个 server 的active、maxFails、fails字段 - 验证 exporter 日志是否成功解析出类似
nginx_upstream_server_active_connections{upstream="api",server="192.168.1.10:8000"}的指标
重点关注的实时负载指标与 PromQL 示例
以下指标能真实反映每个 upstream 节点的瞬时压力与稳定性：
-
nginx_upstream_server_active_connections{upstream=~"xxx"}：每个节点当前活跃连接数，突增可能预示慢接口或连接泄漏 -
nginx_upstream_server_requests_total{upstream=~"xxx"}：单位时间请求数，配合rate()计算 QPS -
nginx_upstream_server_response_msec{upstream=~"xxx"}：上游响应耗时（毫秒），可用histogram_quantile(0.95, ...)查 P95 延迟 -
nginx_upstream_server_healthcheck_fails_current{upstream=~"xxx"}：当前连续失败次数，结合fall=3配置可判断是否已触发剔除
例如查看 api 组中延迟最高的节点：topk(3, nginx_upstream_server_response_msec{upstream="api"}[5m])
告警与可视化建议
仅看数字不够，需建立轻量但有效的反馈闭环：
- 对单节点设置连接数阈值告警：当
nginx_upstream_server_active_connections > 200持续 2 分钟，触发 P3 告警 - 识别异常抖动：用
stddev_over_time(nginx_upstream_server_active_connections[5m]) > 50发现不稳定节点 - Grafana 中按
upstream和server标签做多维下钻面板，叠加连接数、QPS、错误率、延迟四象限视图 - 避免全量采集开销：若使用 NGINX Ingress，注意默认屏蔽
nginx_ingress_controller_ingress_upstream_latency_seconds等高基数指标以防内存泄露
