nginx worker进程监控需结合os级观测与轻量工程手段：通过pgrep/ps验证进程存在性，用top/lsof/ps分析cpu、连接数、rss差异，结合ss和日志确认真实服务状态，并用脚本定时校验+告警。
Nginx 的多进程架构中，master 进程负责管理，worker 进程实际处理请求。但 Nginx 本身不暴露每个 worker 的独立运行指标——监控子进程（即 worker）状况，不能依赖 stub_status，而需结合操作系统级观测与轻量工程手段。
直接看 worker 进程是否存在且活跃
worker 是标准 Linux 进程，名字为 nginx: worker process，可通过以下方式快速确认：
-
pgrep -f "nginx: worker process"：返回 PID 列表，数量应等于配置中的worker_processes值 -
ps aux | grep "nginx: worker"：观察用户（如www-data）、启动时间、CPU 和 RSS 列，初步判断是否异常挂起或僵死 -
systemctl is-active nginx && pgrep -f "nginx: master"：必须同时满足，否则 worker 可能是残留进程，不可靠
用系统资源指标间接反映 worker 负载
每个 worker 独立调度，其资源使用差异能体现实际工作强度：
- CPU 占用：
top -p $(pgrep -f "nginx: worker" | xargs | tr ' ' ',')，按%CPU排序，持续高于 80% 的 worker 可能正处理长连接或复杂逻辑 - 打开文件数（近似活跃连接）：对单个 PID 执行
lsof -p <pid> | wc -l</pid>，数值明显偏离均值（如其他 worker 在 300～500，某一个达 1200）说明连接分发不均或存在连接堆积 - RSS 内存：
ps -o pid,rss,comm -C nginx | grep worker，若某 worker RSS 持续增长且不回落，需排查缓存泄漏或大 body 未释放
验证 worker 是否真正响应请求
进程存在 ≠ 正常服务。可做两层校验：
- 检查监听状态：
ss -tnlp | grep ':80\|:443'，确认端口由当前 worker 所属 master 持有（PID 匹配） - 抓包或日志关联：临时开启
log_format debug '$pid $remote_addr — $request';，在 access.log 中看到不同 PID 处理请求，说明负载已实际分发
让监控可持续、可告警的实用做法
无需引入重型工具，用脚本+cron 即可落地：
- 每 2 分钟执行一次：检查 worker 数量是否匹配配置、最高 CPU worker 是否连续 3 次 >90%、是否有 worker 的 lsof 数超阈值（如 2000）
- 异常时记录到
/var/log/nginx/monitor.log并触发systemctl reload nginx（平滑重启前先nginx -t） - 配合
journalctl -u nginx --since "2 hours ago" | grep -i "worker.*exit\|segfault"，捕获静默崩溃
不复杂但容易忽略
