error_log虽不直接记录资源使用率，但通过“cannot allocate memory”等错误信号可判断硬件是否达临界点，需结合free、top、stub_status等交叉验证定位真实瓶颈。
error_log 本身不直接记录 CPU、内存或磁盘使用率，但它能暴露硬件资源是否已触达临界点——不是“用了多少”，而是“扛不住了”。关键在于识别那些由资源不足引发的典型错误信号，再结合系统状态交叉验证。
看 error_log 中的资源耗尽类错误
这些错误不是配置问题，而是硬件能力被推到极限的明确提示：
-
“Cannot allocate memory”：Nginx 进程申请内存失败，大概率是物理内存或 swap 耗尽，需立刻查
free -h和cat /proc/meminfo - “worker_connections are not enough”：连接数超限，表面是配置小，实则常因 CPU 处理不过来（导致连接堆积）或内存不够（无法为每个连接分配缓冲区）
-
“open() … failed (24: Too many open files)”：文件句柄耗尽，根源常是系统级
ulimit -n或 Nginx 的worker_rlimit_nofile设置过低——而这又受限于可用内存（每个连接约需几 KB 句柄相关结构） - “upstream timed out” 高频出现且伴随 CPU idle 率低：说明后端响应慢，但若同时观察到 Nginx worker 进程 CPU 占用持续 >90%，就可能是 SSL 解密、gzip 压缩等 CPU 密集任务拖垮了处理能力
用 debug 日志定位隐性瓶颈
默认 error_log 不会告诉你“共享内存 zone 满了”，但启用 debug 后可捕获真实压力点：
- 临时加
error_log /var/log/nginx/debug.log debug;，重启后搜索zone is full—— 这说明limit_req_zone或proxy_cache_path keys_zone内存不足，需扩容对应共享内存大小 - 搜
ssl handshake相关 debug 行，若大量 TLSv1.2 握手失败重试，而 TLSv1.3 成功率高，说明旧协议在消耗过多 CPU（尤其单核），应推动客户端升级或调整 cipher suite - 注意：
debug日志量极大，仅用于短时诊断，避免填满磁盘
把 error_log 和 stub_status 数据对齐看
单独看日志容易误判，必须和实时状态联动分析：
- 如果 error_log 频繁报
limiting requests, excess: 1.000，同时/nginx_status显示Waiting占比 >95%、Writing持续 >100，说明大量长连接空闲等待，但新请求进来时因 zone 满或内存不足被丢弃——这时加内存比加 CPU 更有效 - 若
accepts ≠ handled差值扩大，且 error_log 出现多条recv() failed (11: Resource temporarily unavailable)，基本确认是 CPU 或网络栈处理不过来，需检查单核利用率是否打满 - 把 error_log 中高频错误的 client IP，和
access_log中$request_time高的请求来源比对，能区分是恶意扫描（IP 集中）、还是正常用户遭遇服务降级（IP 分散）
统计高频错误辅助判断资源倾向
用简单命令快速定位主导性问题：
-
grep "error" /var/log/nginx/error.log | awk '{print $8}' | sort | uniq -c | sort -nr—— 看哪类错误最多，是内存？连接？还是上游超时？ -
awk '/limiting requests/ {print $12}' /var/log/nginx/error.log | sort | uniq -c | sort -nr | head -5—— 查出最常触发限流的客户端 IP，判断是否为爬虫或异常流量压垮资源 - 配合
ps aux --sort=-%mem | grep nginx和top -p $(pgrep nginx)，确认错误爆发时段是否对应内存或 CPU 使用峰值
