nginx worker进程健康需绕过master直接监控：通过pgrep/ps验证存在性与活跃度，结合cpu、lsof连接数、rss内存判断负载均衡与异常，再以ss和日志pid交叉校验真实服务状态，最后用脚本定时巡检并告警。
Nginx 的多进程架构中，Master 进程不主动监控 Worker 的实时运行状态，只通过 SIGCHLD 和 waitpid() 感知其退出事件；要掌握 Worker 是否真正在工作、负载是否均衡、有无卡死或内存异常，必须绕过 Master，直接从操作系统和请求层入手。
确认 Worker 进程是否存在且活跃
Worker 是标准 Linux 进程，命令行为 nginx: worker process。可用以下方式快速验证：
-
pgrep -f "nginx: worker process"：返回 PID 列表，数量应严格等于配置中的worker_processes值 -
ps aux | grep "nginx: worker"：观察启动时间、用户（如www-data）、CPU 和 RSS，若某 worker 启动时间远早于 reload 时间但长期无 CPU 活动，可能已僵死 - 必须同时满足：
systemctl is-active nginx为active，且pgrep -f "nginx: master"有输出——否则 worker 可能是残留进程，不可信
用系统资源指标判断实际负载
每个 Worker 独立调度，其资源使用差异可反映真实工作强度：
-
CPU 占用：执行
top -p $(pgrep -f "nginx: worker" | xargs | tr ' ' ',')，按 %CPU 排序；持续高于 80% 的 worker 可能正处理长连接、复杂 rewrite 或上游阻塞 -
打开文件数（近似活跃连接）：对单个 PID 执行
lsof -p <pid> | wc -l</pid>；若明显偏离均值（如其他在 300～500，某一个达 1200），说明连接分发不均或存在堆积 -
RSS 内存：用
ps -o pid,rss,comm -C nginx | grep worker查看；若某 worker RSS 持续缓慢上涨且不随请求下降而回落，需排查缓存泄漏或大 body 未释放
验证 Worker 是否真正响应请求
进程存在 ≠ 正常服务。需做两层交叉校验：
- 检查监听状态：
ss -tnlp | grep ':80\|:443'，确认端口由当前 master 的 PID 持有，且 worker 进程的父 PID（PPID）与该 master 一致 - 日志关联验证：临时启用
log_format debug '$pid $remote_addr — $request';，在access.log中看到多个不同 PID 处理请求，说明负载已实际分发，而非某个 worker 独占
让监控可持续、可告警
无需重型工具，脚本 + cron 即可落地：
- 每 2 分钟执行一次：检查 worker 数量是否匹配配置、最高 CPU worker 是否连续 3 次 >90%、是否有 worker 的
lsof数超阈值（如 2000） - 异常时记录到
/var/log/nginx/monitor.log，并触发nginx -t && systemctl reload nginx - 配合
journalctl -u nginx --since "2 hours ago" | grep -i "worker.*exit\|segfault"，捕获静默崩溃
