在 Nginx 多进程模型中，通过 log_format 添加 $pid 变量可直接在访问日志中记录 worker 进程 ID，从而精准定位单个 worker 的负载、响应异常与连接堆积问题，无需额外模块；配合 awk、ps、lsof 等命令可快速分析各 worker 请求量、耗时、错误率及系统资源占用，并建议用 Bash 脚本实现自动化监控与告警。
在 Nginx 多进程模型中，直接在访问日志里记录 worker 进程 ID（PID），是定位单个 worker 负载、排查连接堆积或响应异常最轻量也最有效的方式。因为每个 worker 是独立调度的 Linux 进程，日志带 PID 后，你就能把请求、资源占用、错误行为一一对应到具体进程，避免“平均值掩盖问题”。
在 log_format 中加入 $pid 变量
Nginx 内置变量 $pid 表示当前处理该请求的 worker 进程 ID，无需额外模块或编译选项，开箱即用。
只需在 http 块中修改或新增日志格式，例如：
然后在 server 或 location 块中启用：
重启或重载 Nginx 后，每条日志开头就会出现处理该请求的 worker PID，如 12345 - 192.168.1.100 [...]。
用日志反推各 worker 的实际负载分布
有了带 PID 的日志，就可以用标准 Linux 工具快速统计每个 worker 承担了多少请求、平均耗时如何、是否集中出错：
- 统计各 worker 请求量：
awk '{print $1}' /var/log/nginx/access-with-pid.log | sort | uniq -c | sort -nr - 查某 PID 的平均响应时间：
awk '$1 == "12345" {sum += $NF; n++} END {print sum/n}' /var/log/nginx/access-with-pid.log（假设 $NF 是 $request_time） - 看哪个 worker 返回了大量 5xx：
awk '$1 == "12345" && $9 ~ /^5/ {n++} END {print n+0}' /var/log/nginx/access-with-pid.log
若发现某个 PID 请求量远高于其他、平均耗时陡增、错误率突升，基本可锁定该 worker 出现连接堆积、缓存泄漏或正处理慢后端请求。
结合系统级指标交叉验证
日志中的 PID 是线索，不是结论。需与 OS 层数据对齐才能确认问题根源：
- 确认该 PID 当前是否真实运行：
ps -o pid,comm,etime,rss,%cpu -p 12345，观察运行时长（etime）、内存（rss）和 CPU 占用 - 检查其打开文件数（近似活跃连接）：
lsof -p 12345 | wc -l，若显著高于其他 worker（如 1500 vs 均值 400），说明连接未及时释放或分发不均 - 对比其 CPU 使用率：
top -p 12345 -n 1 -b | tail -1 | awk '{print $9}'，持续 >85% 需关注是否陷入计算密集型逻辑或阻塞调用
特别注意：若日志中有某 PID，但 ps 查不到，说明该 worker 已崩溃退出，Nginx master 未及时拉起（可能配置了 worker_shutdown_timeout 或存在 fork 失败），此时应检查 error.log 和系统资源（如 ulimit）。
自动化监控建议
人工查日志+ps 效率低，推荐写一个轻量脚本定时执行：
- 每 2 分钟扫描 access-with-pid.log 最新 1000 行，提取各 PID 的请求数、5xx 数、平均 request_time
- 同时用
pgrep -f "nginx: worker"获取当前存活 PID 列表，比对是否有“日志有、进程无”的残留 ID - 任一 worker 的请求占比超 40% 或 request_time 均值超全局均值 2 倍，触发告警并记录到 monitor.log
这类脚本无需依赖 Prometheus 或 ELK，纯 Bash + cron 即可落地，适合中小规模生产环境。
