需精准采集$upstream_status中后端返回的5xx、实时计算占比，再通过proxy_next_upstream重试、error_page兜底及动态配置热更新实现自动化容错。
要监控 Nginx 转发给后端产生的 5xx 错误占比，并据此触发自动化容错，关键在于：**精准采集 upstream 返回的 5xx 状态、实时计算比例、结合日志与指标驱动决策，再联动 proxy_next_upstream 和 error_page 实现自动降级或重试。** 单靠 access_log 统计客户端收到的 5xx 是不够的——那可能是 Nginx 自身错误（如 500 配置异常），而你要监控的是“转发后被后端返回的 5xx”，即真正反映后端健康度的信号。
一、从日志中分离并统计后端返回的 5xx
Nginx 默认 access_log 记录的是响应给客户端的状态码，无法区分是 Nginx 自身生成（如 500 因 rewrite 失败）还是上游返回（如后端 PHP 报 500）。需通过 $upstream_http_content_type、$upstream_status 和 $upstream_addr 等变量构造自定义日志格式：
- 在 http 块中定义日志格式：log_format upstream_log '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$upstream_addr" $upstream_status $request_time $upstream_response_time';
- 在 location 或 server 块中启用：access_log /var/log/nginx/upstream.log upstream_log;
- $upstream_status 是核心字段：它只在 proxy_pass 场景下记录后端实际返回的状态码（如 502/503/504），值为 “-” 表示未走 upstream（如静态文件）或连接失败；
- 用脚本（如 awk + bash）每分钟解析 upstream.log，统计 5xx 出现次数与总 upstream 请求次数，算出占比（例如：503+504 占所有非“-” upstream_status 的 8.2%）。
二、用 Prometheus + nginx-prometheus-exporter 实时抓取与告警
日志方案适合离线分析，但要实现秒级监控与自动容错联动，推荐指标化方案：
- 启用 Nginx stub_status，并部署 nginx-prometheus-exporter（监听
/nginx_status）； - Exporter 会暴露
nginx_upstream_requests_total{upstream="backend",status="5xx"}等指标； - 在 Prometheus 中写 recording rule，计算滚动窗口内 5xx 占比：rate(nginx_upstream_requests_total{status="5xx"}[5m]) / rate(nginx_upstream_requests_total[5m])；
- 配置 Alertmanager 告警规则：当该比值连续 2 分钟 > 5% 时，触发 webhook 调用脚本或向配置中心推送“后端质量下降”事件。
三、基于监控结果动态激活容错机制
监控本身不执行容错，需将结果映射到 Nginx 运行时行为。有两类主流方式：
- 静态预置 + 条件激活：在 upstream 块中提前配置 backup 节点和健康检查参数，并用 proxy_next_upstream 显式启用对 502–504 的重试：proxy_next_upstream error timeout http_502 http_503 http_504; 同时设 max_fails=2 fail_timeout=30s，让 Nginx 自动踢出持续返回 5xx 的节点；
- 动态配置热更新：当 Prometheus 告警触发时，由外部脚本修改 Nginx 配置（如临时提升某 backup 节点 weight、或切换 upstream 指向灾备集群），再执行 nginx -s reload ——注意 reload 不中断连接，适合灰度切换；
- 兜底增强：配合 error_page 502 503 504 /maintenance.html; 和 proxy_intercept_errors on;，确保即使重试失败，也返回友好页面而非裸错。
四、验证容错是否生效的关键日志字段
调试阶段必须确认重试与降级真实发生，重点观察 error.log 中的以下线索：
- 出现 upstream prematurely closed connection 或 upstream timed out → 触发 retry 的原始原因；
- 出现 upstream: "http://backend1" 后紧接 upstream: "http://backup" → 表明 next_upstream 已切换；
- access_log 中同一请求的 $upstream_addr 字段显示多个地址（如
10.0.1.10:80, 10.0.1.11:80），且 $upstream_status 为503, 200→ 证实重试成功； - 若启用 proxy_cache_use_stale error timeout http_500–504，日志中会出现 cached valid response 提示，说明已启用缓存降级。
