error_log 本身不能直接监控进程重启，但设为 notice 或更高级别并置于全局块时可记录 master/worker 启动、重载、退出等事件；子块中的 error_log 仅记录请求错误。
error_log 本身不能直接“监控”进程重启，但它能记录 Nginx 主进程（master）和工作进程（worker）的启动、重载、退出等生命周期事件——前提是日志级别设为 notice 或更高（如 info、debug），且配置位于全局块（main 上下文）。
全局 error_log 是记录进程重启信息的唯一有效位置
只有放在 nginx.conf 最外层（user、pid、events 等指令所在层级）的 error_log，才能捕获 master 进程自身的行为。子块（如 http、server）中的 error_log 不记录进程级事件，只管请求处理错误。
- 推荐写法（放在 events 块之前）：error_log /var/log/nginx/error.log notice;
- notice 级别会记录：“starting worker processes”、“exiting”、“reconfiguring”、“signal 1 (SIGHUP) received” 等关键动作
- info 级别会额外记录模块加载、cycle 初始化等细节；emerg 级别则包含进程崩溃前的最后输出
如何确认重启行为是否被记录
执行一次平滑重载（nginx -s reload）或手动重启后，立即查看日志：
-
tail -n 20 /var/log/nginx/error.log —— 正常应看到类似：
2026/07/07 17:58:23 [notice] 1234#1234: signal 1 (SIGHUP) received from 5678, reconfiguring2026/07/07 17:58:23 [notice] 1234#1234: reconfiguring2026/07/07 17:58:23 [notice] 1234#1234: using the "epoll" event method2026/07/07 17:58:23 [notice] 1234#1234: start worker processes - 若没看到这些，检查：
– error_log 路径是否存在、Nginx 用户（如 www-data）是否有写权限
– 是否误将 error_log 放在了 http 或 server 块内
– 当前生效配置是否真包含该语句（可用 nginx -T | grep error_log 验证）
结合 systemd 日志交叉验证更可靠
systemd 会记录进程启停的完整上下文，尤其当 master 异常退出时，error_log 可能来不及写入就中断。此时 journalctl 更完整：
- journalctl -u nginx -n 50 -e --since "2 minutes ago" —— 查看最近重启全过程
- 关注含 “Started nginx”、“Stopping nginx”、“Process exited”、“Main process exited” 的行
- 若发现 “exit code=exited, status=1/FAILURE”，说明启动失败，需回看 nginx -t 输出或 stderr，而非依赖 error_log
自动捕获异常重启的小技巧
仅靠人工翻日志效率低，可加轻量脚本辅助盯盘：
- 用 grep -q "exiting\|exit.*status" /var/log/nginx/error.log 判断近期是否有非预期退出
- 配合 systemctl is-failed nginx 检查服务当前是否处于 failed 状态
- 把这两条写进 cron，每分钟跑一次，异常时触发告警（如 echo “Nginx crash detected” | mail -s …）
