nginx 默认 access_log 不记录 worker 进程 id；需 ≥1.19.10 版本并配置 log_format with $pid 变量，日志首字段才为当前写入 worker 的 pid，但非请求全程唯一标识。
默认情况下，Nginx 的 access log 和 error log 是所有 worker 进程共用同一个文件的，不会按 worker 进程区分写入。所以日志中本身**不带 worker ID 信息**，也就不存在“不同 worker 进程日志天然分离”的前提——你看到的是一份混写的日志流。
为什么看不到 worker 进程标识？
Nginx 默认日志格式不包含 worker 相关字段（如 PID 或 worker 序号）。所有 worker 进程以追加方式写入同一文件，内核保证写入原子性（对短行日志），但行与行之间无归属标记。
- worker 进程是 fork 出来的子进程，共享打开的日志文件描述符
- log 模块写日志时，不主动插入进程 ID、worker 编号等上下文
- 除非手动修改日志格式或使用第三方模块，否则原始日志无法反推某行来自哪个 worker
想归集分析 worker 级别行为？可行方案
核心思路：让每条日志自带可识别的 worker 标识。有以下几种实用方式：
-
在 log_format 中加入 $pid 变量（Nginx ≥ 1.11.12）：
log_format with_pid '$pid - $remote_addr - $request - $status';
$pid 是当前 worker 进程的真实 PID，重启后会变，但同一运行期内可唯一标识 worker -
配合 systemd 或容器环境，用外部进程名/标签隔离日志：
比如用 systemd 启动多个 Nginx 实例（每个实例设 worker_processes 1），再通过 Journalctl 按 unit 名过滤；或在 Docker/K8s 中为每个 worker 分配独立 sidecar 日志采集器（不推荐，违背 Nginx 设计初衷） -
用 Lua 模块（如 lua-resty-logger-socket）动态注入 worker_id：
在 init_worker_by_lua_block 中设置全局 worker_id 变量，在 log_by_lua_block 中写入自定义日志字段（需额外部署和日志收集链路）
已有混合日志，还能区分 worker 吗？
基本不能可靠还原。仅在极少数场景下有辅助线索：
- 如果开启了 error_log ... debug;，部分 debug 级日志会自带 [pid:xxx] 前缀（但 access log 永远不会）
- 若系统启用了 auditd 或 eBPF 工具（如 bpftrace），可实时捕获 write() 系统调用并关联 PID，但这属于外部可观测性方案，不是日志解析范畴
- 时间戳 + 请求特征（如长连接、特定 UA、固定 IP）+ worker 并发数估算，只能做粗略推测，不可用于精准归因
真正需要 worker 维度分析？先确认是否必要
多数性能问题（如某个 worker 卡住、CPU 飙高）应优先通过系统工具定位：
- 用 ps -o pid,comm,psr,pcpu -C nginx 查看各 worker 的 CPU 和绑定 CPU 核心（psr）
- 用 strace -p $PID 抓单个 worker 的系统调用阻塞点
- 用 nginx -T 确认是否启用了可能引发 worker 不均衡的模块（如某些不支持多 worker 的第三方模块）
