监控 nginx 吞吐量需结合 stub_status 差分计算 qps 与定制 access_log 流式聚合字节数，按业务类型分离统计，并联动 active connections、accepts/handled 等指标定位瓶颈，同时打标签实现多维分析。
监控 Nginx 的请求吞吐量，核心是准确获取单位时间内的请求数（QPS）或字节数（如 MB/s），并区分业务类型（如静态资源、动态接口），避免混杂统计。Nginx 本身不直接暴露“吞吐量”数值，但可通过两种互补方式实现：一是用 stub_status 模块实时采集累计计数器并做差分计算；二是用 定制 access_log 记录关键字段，再流式聚合。
用 stub_status 获取每秒请求数（QPS）
这是最轻量、最常用的方式，适合监控整体请求速率：
- 确认模块已启用：
nginx -V 2>&1 | grep 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> } - 访问该路径返回类似内容：
Active connections: 42<br> server accepts handled request<br> 123456 123456 234567<br> Reading: 0 Writing: 3 Waiting: 39
其中request是启动以来总请求数，需定时抓取两次值，用差值除以时间间隔得出 QPS - 建议采样间隔为 5–15 秒：太长会掩盖突发流量，太短易受网络抖动干扰；务必由同一监控客户端发起请求，保证时间对齐
用定制日志监控静态资源吞吐（MB/s）
若需按资源类型（如 JS/CSS/图片）单独统计带宽消耗，必须分离日志：
- 为静态路径单独配置
location，例如：location ~* \.(js|css|png|jpg|woff2)$ {<br> log_format static_bytes '$time_local $uri $status $body_bytes_sent';<br> access_log /var/log/nginx/static_bytes.log static_bytes buffer=64k flush=3s;<br> } -
$body_bytes_sent是实际发给客户端的响应体字节数，比$bytes_sent更准确（不含响应头） - 用流式命令实时聚合：例如每分钟汇总字节数，再换算为 MB/s
tail -n 0 -f /var/log/nginx/static_bytes.log | awk '{sum += $4} NR%60==0 {print strftime("%H:%M"), sum/1024/1024/60; sum=0}' - 高精度场景（如秒级）建议接入 Prometheus + nginx-prometheus-exporter，配合
logrotate按秒切分日志
结合指标交叉验证瓶颈位置
单看吞吐数字无法定位问题，需联动其他指标判断根因：
- 当 QPS 上升但
Writing连接数逼近worker_connections上限时，说明发送能力已达瓶颈（可能是网卡带宽、内核 socket 缓冲区或后端响应慢） - 若
Waiting数值长期偏高而 QPS 未增长，可能是客户端 keep-alive 复用率低，或 CDN 缓存命中率差，导致无效连接堆积 - 检查
accepts != handled：差值即丢弃连接数，常见于worker_connections不足、系统文件描述符耗尽或net.core.somaxconn过低 - 计算
requests / handled比值：低于 1.2 表明连接复用差，应检查客户端超时设置或 upstream keepalive 配置
打标签+统一采集支撑多维分析
生产环境需把吞吐数据关联到具体节点身份，才能有效对比和告警：
- 采集脚本或 exporter 应自动注入标签，例如：
env=prod、role=cdn-edge、ip=10.10.1.12、zone=cn-east-1a - Grafana 中可按
zone分组绘制 QPS 折线图，快速识别某可用区流量异常；也可用sum by (role)查看 API 层与静态层流量占比 - 若某节点 QPS 持续显著低于同组其他节点（如相差 3 倍以上），且
Active connections却很高，大概率是上游健康检查异常或负载权重未生效
