直接看日志判断Nginx稳定性，关键在于错误的分布、频次与趋势：高危alert反复出现预示权限或上游失联，中危error持续上升反映后端崩溃，低危warning长期存在可能引发资源瓶颈；访问日志中5xx突增、响应时间偏移、高频异常404/403揭示隐性不稳定；结合7天趋势对比、时段规律、日志延迟及进程内存、worker异常占比、轮转状态交叉验证，才能全面评估稳定性是否持续退化。
直接看日志就能判断 Nginx 是否稳，关键不是“有没有错误”，而是“错误怎么分布、是否在恶化”。工具只是放大器，真正决定稳定性的，是日志里异常的模式、频率和趋势。
盯住错误日志里的异常等级与频次
错误日志（/var/log/nginx/error.log）是稳定性最直接的晴雨表。用日志分析工具（如 ELK、GoAccess 或自定义脚本）提取 alert/error/warning 级别条目，并按出现次数排序：
- 高危（alert）反复出现：比如 “open() failed (13: Permission denied)” 或 “connect() failed (111: Connection refused)”，说明权限或上游服务已失联，可能随时导致请求失败；
- 中危（error）持续上升：如 “recv() failed (104: Connection reset by peer)” 大量增加，往往对应后端崩溃或网络抖动；
- 低危（warning）长期存在：像 “could not build optimal server_names_hash” 这类配置警告，虽不立即中断服务，但会拖慢解析效率，长期积累可能引发资源瓶颈。
从访问日志识别隐性不稳定信号
访问日志（/var/log/nginx/access.log）看似记录“成功请求”，实则藏着稳定性隐患：
- 状态码异常集中：5xx 错误占比突然升至 2% 以上，或 499（客户端主动断开）大量出现，常意味着后端响应慢、超时或用户因卡顿频繁刷新；
- 响应时间（$request_time）分布偏移：正常时 95% 请求应在 200ms 内完成，若中位数跃升至 800ms 且长尾明显，说明处理链路存在阻塞；
- 同一 IP 短时高频 404/403：不是攻击就是前端路由配置错乱，反复触发错误逻辑，消耗 worker 进程资源。
用时间维度验证稳定性是否持续退化
单次扫描日志只能看到快照，真正评估稳定性要看变化趋势：
- 对比最近 7 天每日的总错误数、5xx 率、平均 request_time，画成折线图——平稳或缓慢下降属健康，阶梯式跳升需立即干预；
- 检查异常是否集中在特定时段：如果每天凌晨 3 点固定出现 “worker process exited on signal 11”，大概率是某个定时任务触发了内存泄漏；
- 观察日志写入延迟：若 error_log 中的时间戳比系统时间晚 5 秒以上，说明磁盘 I/O 或 syslog 服务已过载，日志本身可能丢失关键现场。
结合进程与资源数据交叉验证
日志异常必须和运行态对齐才有意义：
- 用工具（如 Prometheus + nginx-exporter）把日志中的 error 次数，和 nginx_process_resident_memory_bytes、nginx_connections_active 指标叠加看——内存持续上涨+错误增多，指向内存泄漏；
- 统计各 worker 进程报错占比：若某一个 worker 的 error 日志占总量 80%，而其他 worker 平稳，大概率是该进程卡死或陷入无限循环；
- 检查日志轮转是否正常：若 access.log 单日增长超 2GB 且未自动切割，可能因磁盘满导致 Nginx 写日志失败，进而触发 panic 行为。
