nginx多进程请求监控需分三层：系统层看cpu/文件描述符/上下文切换，内核层用stub_status分析reading/writing/waiting连接状态，请求层通过$pid打标日志实现worker维度故障定位。
在 Nginx 多进程架构下做请求监控，核心是区分「进程级资源行为」和「请求级业务表现」，不能只看总连接数或平均响应时间，而要结合 Master-Worker 模型特点，从系统层、Nginx 内核层、请求链路层三层联动观察。
看清进程分工与监控边界
Master 进程不处理请求，只管配置加载与 Worker 生命周期；真正承载请求的是每个 Worker 进程。因此：
- 进程存活监控：用 ps aux | grep nginx 确认 Master 是否运行、Worker 数量是否符合配置（如
worker_processes 4） - 单 Worker 负载不均预警：若某 Worker 的 CPU 使用率长期高于其他 Worker 2 倍以上，说明事件分发或负载均衡策略可能失衡
- 避免误判“多进程=多线程”：每个 Worker 是单线程异步模型，不能靠线程堆栈查阻塞，而要看其 epoll 事件循环是否积压（通过
nginx_status中 Reading/Writing/Waiting 指标判断）
启用并解读 stub_status 实时指标
必须开启 ngx_http_stub_status_module，并在 server 块中配置一个受保护的 location：
- Active：当前所有 Worker 中活跃连接总数（非并发请求数，而是已建立但未关闭的 TCP 连接）
- Reading：正在读取客户端请求头的连接数 —— 若持续偏高，可能是客户端慢速攻击或大 Body 上传未完成
- Writing：正在向客户端发送响应的连接数 —— 若突增且伴随高延迟，需检查后端响应或网络吞吐
- Waiting：处于 keepalive 状态空闲等待的连接数 —— 合理值应占 Active 的 60%~90%，过低说明连接复用不足，过高则可能后端响应慢拖住连接
按 Worker 维度聚合请求日志分析
默认 access log 不带 Worker ID，但可通过 $pid 变量打标，实现每条日志归属到具体 Worker 进程：
- 在 http 块中定义日志格式：
log_format detailed '$pid $remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_time $upstream_response_time'; - 配合
access_log /var/log/nginx/access.log detailed; - 分析时可执行：
awk '$1 == "12345" {print $0}' /var/log/nginx/access.log | grep "502"，快速定位某个 Worker 是否集中报错 - 该方式能发现“局部故障”，比如某 Worker 因内存泄漏导致频繁 502，而其他 Worker 正常
结合系统指标交叉验证
多进程模型下，请求异常往往先反映在系统资源上：
- CPU：用 top -Hp $(pgrep nginx) 查看各 Worker 线程的 CPU 占用，单个超过 80% 需警惕
- 文件描述符：每个 Worker 独立持有 fd，
lsof -p [worker_pid] | wc -l若接近worker_rlimit_nofile设置值，说明连接耗尽风险高 - 上下文切换：用 vmstat 1 观察 cs（context switch）值，持续 >5000 表明进程调度压力大，可能因 worker_processes 过多或 CPU 亲和性未配置
