要记录nginx故障转移过程中的错误日志，核心是显式配置error_log级别为warn及以上，并配合proxy_next_upstream、自定义upstream_log格式及健康检查模块，使连接失败、超时、502/503等触发事件及节点下线行为完整落盘。
要记录 Nginx 故障转移过程中的错误日志，核心是让 Nginx 明确感知后端服务不可用，并将相关失败事件（如连接超时、拒绝连接、502/503 等）输出到错误日志中。默认情况下，Nginx 已会记录部分故障事件，但需合理配置才能完整捕获故障转移行为。
确保 error_log 级别足够高
Nginx 默认的 error_log 级别通常是 error，但某些关键故障细节（例如 upstream 尝试重试、健康检查失败）只在 warn 或 info 级别下输出。建议在 http 或 stream 块中显式设置：
- error_log /var/log/nginx/error.log warn; —— 记录连接拒绝、超时、上游服务器标记为 down 等关键事件
- 若需更细粒度（如每次 upstream 重试），可临时设为 info，但生产环境慎用，避免日志爆炸
启用 upstream 模块的详细日志（尤其 proxy_next_upstream_tries 和 log_format）
Nginx 不会自动记录“哪次请求触发了故障转移”，但可通过自定义 log_format + proxy_next_upstream 配合，间接体现故障转移过程：
- 在 http 块中定义含 upstream 相关变量的日志格式：
log_format upstream_log '[$time_local] $remote_addr - $upstream_addr - $upstream_status - $upstream_response_time - $request - $status'; - 在 location 中启用重试并指定日志格式：
proxy_next_upstream error timeout http_502 http_503;
proxy_next_upstream_tries 3;
access_log /var/log/nginx/upstream.log upstream_log; - 这样当请求因某台后端失败而转向另一台时，$upstream_addr 会显示实际通信的后端地址（如 10.0.1.10:80, 10.0.1.11:80），$upstream_status 可能出现 502, 503, -（失败无响应），帮助定位哪次尝试失败、哪次成功
配合健康检查（keepalive 或第三方模块）记录主动探活失败
被动重试（proxy_next_upstream）只能在请求时发现故障；若想提前记录“某节点已被踢出集群”，需主动健康检查：
- 使用官方 ngx_http_upstream_module 的 health_check（需 Nginx Plus）或开源替代方案（如 nginx-upstream-check-module）
- 启用后，模块会在后台定期探测，失败时在 error_log 中输出类似：
[error] ... upstream check failed: port: 80, peer: 10.0.1.12 - 这类日志明确标识“节点被标记为 down”的时间点和原因，是故障转移前的关键信号
注意 stream 模块（TCP/UDP 转发）的日志差异
如果故障转移发生在四层（如数据库、Redis 代理），需使用 stream 上下文，其日志机制与 http 不同：
- stream 块中也支持 error_log 和 log_format，但变量不同（如 $upstream_bytes_received, $upstream_connect_time）
- 启用 log_format 后，需在 server 块中用 access_log 显式引用，否则不生效
- TCP 层故障（如 connection refused、timeout）同样会记入 error_log，级别为 error 或 warn，取决于失败类型
