nginx本身不提供跨节点全局吞吐聚合，需各节点启用stub_status并统一采集requests差值计算qps，结合标签化与handled/accepts比值分析健康状态。
在高可用架构中，Nginx 本身不直接提供跨节点的全局吞吐量聚合能力，但可通过每个节点独立暴露 stub_status 接口，再配合统一采集与时间对齐计算，实现各节点真实 QPS（每秒请求数）的可观测性。关键不在“单次看数”，而在“持续采样+差值归一化”。
确保每个 Nginx 节点都启用并安全暴露 stub_status
所有后端 Nginx 实例必须一致启用该模块，并限制访问范围：
- 先验证模块存在：
nginx -V 2>&1 | grep -o with-http_stub_status_module，无输出需重新编译并添加--with-http_stub_status_module - 在每个节点的
server块中配置专用路径，例如：location /nginx-status {<br> stub_status on;<br> access_log off;<br> allow 127.0.0.1;<br> allow 10.10.0.0/16; # 监控服务器所在网段<br> deny all;<br>} - 避免使用
/stub_status这类通用路径，推荐带环境标识（如/status-prod），防止误触或冲突
用两次采样差值算出各节点真实 QPS
stub_status 返回的是累计计数器，不能直接读取“当前 QPS”——必须定时抓取 requests 字段并做差分：
- 假设节点 A 在 t₁ 时刻返回：
requests 123456；30 秒后 t₂ 返回：requests 124289 - 则该节点近似 QPS = (124289 − 123456) ÷ 30 ≈ 27.8
- 建议采样间隔 ≤ 15 秒（高波动业务可设为 5 秒），太长会掩盖突发峰值，太短则噪声大
- 务必用同一监控客户端发起请求，避免因网络抖动导致时间戳不同步
统一采集 + 标签化打点，支撑多维对比
单看数字没意义，需把 QPS 关联到具体节点身份和角色：
- 采集脚本或 exporter（如
nginx-prometheus-exporter）应自动注入标签：env=prod、role=api-gateway、ip=10.10.1.12、zone=cn-east-1a - 在 Grafana 中可按
zone分组绘制折线图，快速识别某可用区整体吞吐骤降；也可用sum by (role)查看 API 层 vs 静态资源层的流量占比 - 若发现某节点 QPS 持续显著低于同组其他节点（如相差 3 倍以上），且
Active connections却很高，大概率是上游健康检查异常或权重未生效
结合 handled 和 accepts 判断节点是否“掉队”
吞吐量只是结果，连接处理能力才是基础。持续观察以下比值可提前预警：
-
accepts != handled：说明有连接被丢弃，常见于worker_connections不足、系统文件描述符耗尽、或内核net.core.somaxconn过低 requests / handled ：表示平均每个连接只处理不到 1.2 个请求，keep-alive 复用率极差，可能是客户端频繁断连或超时设置过短-
Writing > 50且持续上升：响应发送慢，需排查后端延迟或 Nginx 缓冲区（proxy_buffer_size等）是否过小
