Nginx访问日志需显式配置$statusCode、$request_time和$upstream_status等字段，避免仅用combined格式；应通过日志聚合分析状态码分布趋势，对接监控系统设置5xx率、502次数等告警规则，并结合$request_uri、$upstream_addr等字段交叉验证定位问题。
Nginx 访问日志默认就记录了 status 状态码（如 200、404、502），这是监控系统健康度最基础也最关键的指标。关键不在于“能不能记”，而在于“怎么记得清楚、查得方便、告得及时”。
确保日志格式包含 $status 并启用访问日志
检查你的 nginx.conf 或站点配置中是否正确定义了日志格式，并在 location 或 server 块中启用了 access_log：
- 推荐自定义日志格式，显式包含状态码、响应时间、上游状态等关键字段：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_time $upstream_status'; - 在 server 或 http 块中启用：
access_log /var/log/nginx/access.log main; - 避免只用默认的
combined格式——它虽含$status，但缺少$request_time和$upstream_status，难以区分是 Nginx 自身问题还是后端超时/挂掉。
用状态码分布快速判断健康趋势
状态码不是孤立数字，要看比例和变化：
- 2xx 比例骤降 + 5xx 比例突增：大概率后端服务异常（如进程崩溃、数据库连不上）；
- 大量 499（客户端主动断开）：可能是前端超时设置过短，或用户网络不稳定；
-
502/503 集中出现：重点关注
$upstream_status是否全为 “-” 或 “502”，确认是 upstream 不可用还是负载均衡转发失败； - 用命令实时观察（每秒刷新）：
tail -f /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c | sort -nr
对接监控系统做持续跟踪
人工看日志只能救火，不能预防。把状态码变成可绘图、可告警的指标：
- 用 Logstash + Elasticsearch + Kibana 或 Filebeat + Loki + Grafana 收集日志，按
status字段聚合，画出 2xx/4xx/5xx 的分钟级占比曲线； - 设置告警规则，例如：
• 连续 3 分钟 5xx 率 > 1%；
• 单分钟内 502 出现次数 > 50 次；
• 200 响应数 5 分钟同比下降 80%（可能被攻击或流量劫持）； - 注意排除爬虫、健康检查请求干扰：可在日志格式中加入
$http_user_agent或用map指令标记内部探针请求，告警时过滤掉。
配合其他字段交叉验证，避免误判
单看 status 容易误导。必须结合上下文才能准确定位问题：
- 看到很多 504？查
$request_time是否接近你设的proxy_read_timeout，再核对后端真实处理耗时； - 大量 404？结合
$request_uri看是否集中在某个新上线接口路径，或是恶意扫描； - 502 高发？比对
$upstream_addr，看是否只打在某台后端，说明该节点已失联但未被摘除； - 加一个简单的 debug 日志格式临时启用：
log_format debug '$time_local $status $request_time $upstream_status $upstream_addr "$request"';
