error_log在notice级别可记录master/worker启动、重载、退出等生命周期事件，需在main块配置并结合ps验证实际进程状态，生产环境建议按需临时启用。
error_log 本身不记录 Nginx 进程树（master/worker）的创建、退出或重启过程，但它能间接反映这些状态变化——关键在于日志级别和信号行为。
启用 notice 级别捕获进程生命周期事件
默认 error 级别会跳过大多数运维提示，而 notice 级别恰好记录 master/worker 启动、重载、平滑退出等关键动作。需在 main 块中明确配置：
error_log /var/log/nginx/error.log notice;- 重启或重载后，日志中会出现类似：
2026/07/07 10:45:22 [notice] 12345#12345: signal process started2026/07/07 10:45:22 [notice] 12345#12345: gracefully shutting down2026/07/07 10:45:23 [notice] 12346#12346: start worker processes
结合信号操作与日志时间戳定位进程行为
Nginx 通过信号控制进程树，每类信号都会触发对应 notice 日志条目：
-
nginx -s reload→ 触发 “signal process started” + “gracefully shutting down” + 新 worker 启动 -
nginx -s quit→ 记录 “gracefully shutting down”，master 进程退出 -
nginx -s stop→ 强制终止，通常无 graceful 日志，但可能伴随 “worker process is terminating” - Worker 异常崩溃时，即使未配 notice，error 级也会记录：
2026/07/07 10:42:11 [alert] 12345#12345: worker process 12347 exited on signal 11 (core dumped)
验证进程树真实状态，不能只依赖日志
notice 日志只是“声明”，不代表实际执行成功。必须交叉验证：
- 用
ps aux | grep "nginx: master\|worker"查看当前存活进程数量与角色 - 检查
pgrep -f "nginx: master process"是否返回 PID - 对比日志中最后一条 “start worker processes” 时间与
ps输出的 worker 启动时间是否一致 - 若日志显示新 worker 启动，但
ps中 worker 数量未增，说明 fork 失败（常见于 ulimit 或内存不足）
生产环境建议：按需开启 notice，避免长期记录
notice 日志信息量适中，适合短期排查进程异常；但不建议长期开启，尤其在高并发场景下：
- 每次 reload、worker 自愈、定时重启都会写入多行 notice，日志增长较快
- 线上稳定运行期间，保持
error_log ... error;即可 - 遇到 worker 频繁退出、reload 后服务中断等问题时，临时切为 notice，查完立刻切回
- 可通过
nginx -s reload生效，无需重启进程
