必须启用--with-http_stub_status_module编译模块，在server块中配置受控location（如/nginx_status），限制IP访问并关闭日志，才能安全获取Active connections、accepts、handled、requests等纯文本指标。
性能优化和监控必须联动，光调参数不看数据等于盲调。Nginx 的连接数、吞吐量等关键指标必须实时可查，才能验证优化是否生效、识别真实瓶颈。
启用 stub_status 模块获取基础运行指标
这是最轻量、原生、无需额外依赖的监控入口。必须在编译时启用 --with-http_stub_status_module（源码安装默认不带，yum 安装通常也不含），否则配置无效。
- 在 server 块中添加 location：
location /nginx_status {
stub_status on;
access_log off;
allow 127.0.0.1;
allow 192.168.31.0/24;
deny all;
}
- 访问
http://your-server/nginx_status返回三行文本：
Active connections: 128
server accepts handled requests
123456 123456 789012
Reading: 0 Writing: 3 Waiting: 125
其中：
— Active connections 是当前总连接数（含 Reading/Writing/Waiting）
— 第二行三个数字分别代表：接受连接数、成功处理连接数、总请求数 → 吞吐量可由单位时间请求增量推算
— Waiting 占比高，说明大量空闲长连接；Writing 持续偏高，可能后端响应慢或响应体大
用 Prometheus + nginx-vts-exporter 实现指标结构化采集
stub_status 输出是纯文本，不适合自动化分析。生产环境推荐接入 Prometheus 生态，核心是 nginx-vts-exporter（VTS = Virtual Host Traffic Status）。
- 它通过解析 Nginx 的
ngx_http_vhost_traffic_status_module模块输出（比 stub_status 更细粒度），暴露标准 Prometheus metrics 接口 - 需重新编译 Nginx 并加载 vhost_traffic_status 模块（非官方模块，但广泛使用）
- 典型指标包括：
—nginx_vts_server_connections_total{state="active"}（实时活跃连接）
—nginx_vts_server_requests_total（每秒请求数 QPS，直接反映吞吐）
—nginx_vts_server_request_seconds_sum（响应耗时，配合 count 可算 P95/P99）
— 按 upstream、vhost、location 维度拆分的流量与错误率 - 搭配 Grafana 面板，就能看到“调大 worker_connections 后 Waiting 连接是否下降”、“keepalive_timeout 调短是否导致 Accepts/Handled 比值升高（连接复用变差）”等因果关系
把监控指标反向驱动优化决策
监控不是摆设，要形成“看指标 → 找瓶颈 → 改配置 → 验证效果”的闭环。
- 若
Active connections长期接近worker_processes × worker_connections上限，且出现拒绝连接日志（accept() failed (24: Too many open files)），说明必须调高worker_connections并同步扩大系统ulimit -n和net.core.somaxconn - 若
Waiting占比持续 >90%，而业务实际并发不高，说明keepalive_timeout设得太长，空耗连接资源，应缩短至 30–60 秒 - 若 QPS 上不去，但 CPU 使用率低、Active connections 也未打满，要检查
worker_processes是否小于 CPU 核心数，或是否没开multi_accept on导致连接接收效率低 - 对比
nginx_vts_server_requests_total和后端应用的请求计数，若前者远大于后者，可能是 Nginx 层缓存未命中或重试导致重复转发，需检查 proxy_cache 或 retry 配置
补充：日志分析作为吞吐与异常的辅助验证手段
access log 开启缓冲后（access_log /path main buffer=16k flush=5s），可用工具如 GoAccess 或 ELK 实时解析，验证监控数据一致性。
- 例如：Prometheus 显示 QPS 突增到 5000，但 access log 中 5xx 错误同步上升 → 可能是后端扛不住，而非 Nginx 瓶颈
- 再如：stub_status 中
Accepts增速远高于Requests→ 大量连接建立但未发请求，可能是健康检查探测过于频繁或客户端异常
