Nginx 中访问日志怎么记录服务进程 ID 分析多进程负载情况-Nginx-PHP中文网

在 nginx 多进程模型中，通过 log_format 添加 $pid 变量可直接在访问日志中记录 worker 进程 id，从而精准定位单个 worker 的负载、响应异常与连接堆积问题，无需额外模块；配合 awk、ps、lsof 等命令可快速分析各 worker 请求量、耗时、错误率及系统资源占用，并建议用 bash 脚本实现自动化监控与告警。

nginx 中访问日志怎么记录服务进程 id 分析多进程负载情况

在 Nginx 多进程模型中，直接在访问日志里记录 worker 进程 ID（PID），是定位单个 worker 负载、排查连接堆积或响应异常最轻量也最有效的方式。因为每个 worker 是独立调度的 Linux 进程，日志带 PID 后，你就能把请求、资源占用、错误行为一一对应到具体进程，避免“平均值掩盖问题”。

在 log_format 中加入 $pid 变量

Nginx 内置变量 $pid 表示当前处理该请求的 worker 进程 ID，无需额外模块或编译选项，开箱即用。

只需在 http 块中修改或新增日志格式，例如：

log_format pid_log '$pid - $remote_addr [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" $request_time $upstream_response_time';

然后在 server 或 location 块中启用：

access_log /var/log/nginx/access-with-pid.log pid_log;

重启或重载 Nginx 后，每条日志开头就会出现处理该请求的 worker PID，如 12345 - 192.168.1.100 [...]。

用日志反推各 worker 的实际负载分布

有了带 PID 的日志，就可以用标准 Linux 工具快速统计每个 worker 承担了多少请求、平均耗时如何、是否集中出错：

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

统计各 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）。