Nginx stub_status指标采集需在多worker、多实例环境下统一暴露、结构化解析并安全中转：本地独立端口暴露、路径避险、仅限127.0.0.1访问、关闭日志；用脚本将纯文本转Prometheus格式写入textfile；取多次请求最大值近似全局连接数；结合Waiting/Reading等分布设动态告警。
直接用监控系统抓取 Nginx stub_status 集群指标，核心不是“集群”本身（stub_status 本质是单进程级指标），而是如何在多 worker、多实例环境下稳定采集、聚合并避免安全风险。关键在于统一暴露方式、结构化解析、可靠中转。
确保每个 Nginx 实例都安全暴露 stub_status 接口
stub_status 不支持跨进程汇总，必须为每台服务器单独配置访问端点：
- 使用独立本地监听端口（如 127.0.0.1:8081），不复用业务端口，避免 location 冲突或 rewrite 干扰
- 路径避开通用名，推荐 /_nxs 或 /nginx-metrics，降低被扫描风险
- 严格限制来源：allow 127.0.0.1; + deny all;，生产环境禁用公网可访问
- 务必关闭日志：access_log off;，防止高频采集压垮磁盘 I/O
用轻量脚本将纯文本转为 Prometheus 可读格式
stub_status 返回的是固定三行纯文本，无法被 Prometheus 直接抓取，需本地脚本做转换：
- 每 10 秒执行一次 curl + awk 提取，例如：
active=$(curl -s http://127.0.0.1:8081/_nxs | awk '/Active connections:/ {print $3}') - 提取 Reading/Writing/Waiting/accepts/handled/requests 全部字段，写入 /var/lib/node_exporter/textfile/nginx.prom
- 输出格式示例：
nginx_stub_active_connections 142
nginx_stub_reading_connections 2
nginx_stub_writing_connections 28
nginx_stub_waiting_connections 112
nginx_stub_accepts_total 156890
nginx_stub_handled_total 156890
nginx_stub_requests_total 423156 - 确保 node_exporter 已启用 textfile collector：--collector.textfile.directory=/var/lib/node_exporter/textfile
识别并应对多 worker 下的统计局限
默认情况下，stub_status 返回的是当前处理请求的 worker 进程的数据，不是全部 worker 的总和：
- 若你看到 Active connections 数值波动剧烈（如从 50 突降到 5），很可能是轮询到了不同 worker
- 要获得近似全局值，可临时设置 accept_mutex off;（仅限调试），但会增加锁竞争，不建议长期开启
- 更稳妥的做法：在采集脚本中连续请求 3–5 次，取最大值作为该实例的活跃连接水位参考
- Prometheus 抓取时加 relabel_configs 标注 instance、region、role，便于后续按集群维度聚合
设置有意义的告警阈值而非固定数字
单纯看 “Active connections > 1000” 容易误报，应结合状态分布与趋势判断真实瓶颈：
- Waiting 占比持续低于 60% → keep-alive 复用率下降，可能后端延迟升高
- Reading 长期高于 Active 的 5% → 关注客户端网络质量或慢速攻击（如 Slowloris）
- accepts – handled 差值持续增长 → accept queue 积压，需检查 net.core.somaxconn 和 worker_connections
- Writing 高且响应时间 P95 上升 → 带宽打满、后端响应慢或大文件传输阻塞
