nginx worker 进程流量需通过组合方案采集：vts模块提供虚拟主机级近似分布；/proc/pid/stat辅助推算；prometheus+exporter+脚本关联请求与内存指标；access_log+$pid+ngxtop实现真正worker粒度http层分析。
Nginx 的 Worker Process 本身不直接暴露每个进程的流量明细，但可通过组合配置与外部工具实现精准采集。关键在于区分「全局流量」和「Worker 级别流量」——前者用内置模块即可获取，后者需借助系统层指标或扩展方案。
用 nginx-module-vts 获取虚拟主机级流量（含各 worker 贡献）
vts 模块虽不按 PID 拆分数据，但它基于共享内存统计，能反映每个 worker 实际处理的请求分布： - 启用后访问 `/status/format/json`，响应中 `serverZones` 和 `upstreamZones` 下的 `requestCounter`、`inBytes`、`outBytes` 是各 server 或 upstream 的累计值 - 若配置了多个 `server` 块且监听不同域名或端口，vts 会自动隔离统计，间接体现不同 worker 处理的流量倾向（尤其当 `worker_processes` > 1 且使用 `accept_mutex off` 时） - 配合 `vhost_traffic_status_filter_by_host on;` 可让统计更贴近实际站点维度注意：vts 不记录单个 worker 进程的实时请求数，但它的计数器由所有 worker 共同更新，高频更新下可近似反映负载分布趋势。
通过 /proc//stat 和 /proc//net/dev 推算单 worker 流量
Linux 内核为每个进程维护网络收发统计，虽非直接流量字节数，但可辅助判断：
- 找出所有 worker PID：pgrep -f "nginx: worker"
- 对每个 PID，读取 /proc/{pid}/stat 中第 40/41 字段（cut -d' ' -f40,41 /proc/{pid}/stat），对应进程累计接收/发送的字节数（需内核支持 CONFIG_PROC_PID_STAT）
- 更可靠的是结合 /proc/{pid}/net/dev（需 worker 绑定独立网络命名空间或使用 cgroup v2），但默认情况下所有 worker 共享 host netns，此法不适用
实际生产中，该路径仅作辅助验证，不建议作为主采集方式。
用 Prometheus + nginx-vts-exporter + 自定义脚本补全 Worker 维度
这是目前最实用的细粒度方案： - nginx-vts-exporter 拉取 vts JSON 数据并转为 Prometheus 指标（如 nginx_vts_server_requests_total） - 同时部署一个轻量脚本，定时执行：pgrep -f "nginx: worker" | while read pid; do echo "nginx_worker_rss_bytes{pid=\"$pid\"} $(ps -o rss= -p $pid)"; done
- 将该脚本输出通过 textfile collector 或 node_exporter --collector.textfile.directory 暴露为指标 - 在 Grafana 中关联 nginx_vts_server_requests_total 与 nginx_worker_rss_bytes，按时间序列对比，识别高 RSS 伴随高 request/sec 的 worker
这样既能看到谁在处理更多请求，又能观察其内存增长是否异常。
日志 + ngxtop 实时反推活跃 worker 负载
虽然日志是全局写入，但可通过 access_log 的 `$pid` 变量打点： - 在 log_format 中加入：log_format main "... pid:$pid ..."; - 重启 Nginx，确保每个请求日志带所属 worker PID - 使用 ngxtop -l /var/log/nginx/access.log --group-by pid 查看各 PID 的 QPS、平均响应时间、错误率 - 结合 tail -f /var/log/nginx/access.log | grep "pid:12345" 可即时跟踪某 worker 的请求流这是唯一真正按 worker 粒度还原 HTTP 层流量行为的方式，无需修改 Nginx 源码或依赖特殊模块。
