crit级别记录真正威胁服务存活的致命事件，如端口被占、权限拒绝致master初始化失败、worker崩溃、配置解析失败致无法启动、内存或共享内存底层资源崩溃等。
crit 级别到底记录哪些错误
crit 级别只记录真正威胁服务存活的致命事件，不是“严重报错”，而是“不处理就挂”的问题。它不会出现 500、502、证书过期、重定向循环这类运行时异常——那些归 error 级别管。crit 实际捕获的是：
• bind() to 0.0.0.0:80 failed (98: Address already in use)
• open() "/var/lib/nginx/tmp/client_body/" failed (13: Permission denied)（且发生在 master 初始化阶段）
• worker process XXX exited on signal 11 (core dumped)
• 配置解析失败导致 master 无法启动（如 nginx.conf 第 87 行多了一个 }）
• 内存分配失败、共享内存初始化失败等底层资源崩溃信号
为什么在高流量下设成 crit 是合理选择
当 QPS 上万、日志写入频次达每秒数百条时，error 级别会混入大量可恢复的瞬时错误（比如上游超时、客户端主动断连），反而掩盖真正致命信号。而 crit 天然过滤掉所有非进程/配置/内核级故障，让运维能一眼锁定：
• 是不是端口被占用了？
• 是不是 worker 因段错误崩了？
• 是不是 reload 后 master 没起来？
注意：crit 不等于“看不见问题”——它把噪音降到最低，把确定性最高的崩溃证据保留下来。磁盘 I/O 压力也直接下降 90% 以上。
如何安全启用并验证 crit 日志有效性
直接在 main 块（即 events 块之前）写：error_log /var/log/nginx/error.log crit;
然后执行：
• nginx -t 确认语法无误
• nginx -s reload 生效（无需重启）
• 立即检查日志是否可写：ls -l /var/log/nginx/error.log，确保 nginx 运行用户（如 www-data）有写权限
• 手动触发一次 crit 级错误验证：临时注释掉 listen 指令后 nginx -t，会报 [emerg]；或用 kill -9 杀一个 worker，观察日志是否出现 exited on signal 记录
容易忽略的两个关键点
第一，crit 日志仍可能为空——这不是配置失败，而是当前系统确实没发生致命错误。不要因此误判为“没生效”，要结合 systemctl status nginx 和 ps aux | grep nginx 看进程状态。
第二，crit 不覆盖 error_log 的作用域规则：你在某个 server 块里单独写了 error_log /path/to/api_error.log error;，那这个文件仍按 error 级别记，和全局 crit 互不干扰。真正要收拢核心崩溃信号，必须确保全局 main 块的 error_log 明确设为 crit，且路径可写。
