nginx 不提供按进程粒度的活跃度监控，stub_status仅返回全局指标；可通过top、lsof、ps等系统命令间接评估各worker负载，或结合openresty+prometheus、telegraf等方案实现细粒度监控。
Nginx 本身不提供按“进程”粒度的活跃度监控（如每个 worker 进程的实时请求数、连接状态等），它的状态页（stub_status）只暴露全局汇总指标。但你可以结合 Nginx 状态页 + 操作系统级工具，间接推断各 worker 进程的负载活跃情况。
理解 Nginx 状态页的局限性
stub_status 模块（需编译启用并配置 location /nginx_status）仅返回三行统计：
- Active connections：当前所有 worker 共享的活跃 TCP 连接总数（含 waiting 状态）
- accepts：Nginx 启动以来接受的总连接数
- handled：成功处理的连接数（通常 ≈ accepts）
- requests：总 HTTP 请求次数
它不区分哪个 worker 处理了哪些请求，也不显示各进程的内存占用、CPU 占用或当前并发请求数。
通过系统命令观察各 worker 进程行为
Nginx worker 进程是独立的 Linux 进程（通常为 nginx: worker process），可通过以下方式评估其相对活跃度：
-
看 CPU 使用率：
top -p $(pgrep -f "nginx: worker")或htop，排序 CPU%，高占比通常说明该 worker 正在密集处理请求（如长连接、复杂 rewrite、大量子请求） -
看打开文件数（连接数近似）：
lsof -p <pid> | wc -l</pid>，worker 打开的文件句柄多数为客户端 socket，数量明显高于其他 worker 可能表示其承担更多活跃连接 -
看 RSS 内存占用：
ps -o pid,rss,comm -C nginx，内存显著偏高可能因缓存数据多、连接堆积或存在泄漏（需结合时间趋势判断）
启用更细粒度的监控方案
若需真正按 worker 维度监控，推荐以下实用组合：
-
OpenResty + lua-resty-prometheus：在 Lua 阶段为每个 worker 记录本地计数器（如
worker.table），再通过 Prometheus 拉取并聚合，支持 per-worker 的 request/sec、upstream latency 等 -
Telegraf + inputs.nginx 插件：采集
stub_status全局指标；同时用inputs.exec调用自定义脚本，遍历/proc/<pid>/fd/</pid>或/proc/<pid>/stat</pid>提取各 worker 的连接数/CPU 时间，输出为指标 -
Systemd + cgroup（高级场景）：将每个 worker 进程放入独立 systemd scope 或 cgroup，用
systemctl status或cgtop查看资源隔离后的使用情况（需修改启动逻辑，生产环境慎用）
小技巧：让 worker 负载更均衡可辅助判断
如果发现某个 worker 长期 CPU 或连接数远高于其他 worker，可能是以下原因：
- 未开启
accept_mutex on（默认开启），导致惊群；或multi_accept off，造成连接分发不均 - 启用了
ip_hash且部分 IP 段流量突增，把请求持续打到固定 worker - 上游服务响应慢，导致该 worker 的连接积压未及时释放
此时可临时用 kill -USR2 平滑重启 worker，观察负载是否重新分布，帮助验证是否为瞬时热点问题。
