通过配置Nginx日志记录$upstream_addr和$upstream_response_time变量，结合curl抽样、awk统计及Prometheus监控，可精准识别上游节点延迟异常与故障根因。
直接看 $upstream_response_time 和 $upstream_addr 这两个变量，配合日志和简单脚本就能测出各节点真实响应延迟。
把延迟数据准确记进访问日志
在 http 或 upstream 所在作用域定义带这两个变量的日志格式：
- 加一行：
log_format upstream_log '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$upstream_addr" "$upstream_response_time"'; - 在
location或server块里用：access_log /var/log/nginx/upstream.log upstream_log; - 重启 Nginx 后，每条日志末尾就会出现类似
"192.168.1.11:8080" "0.023"或"192.168.1.12:8080,192.168.1.11:8080" "0.041,0.019"的记录，能清楚对应到哪台机器、耗时多少、是否重试
用 curl 快速抽样验证
写个轻量脚本循环发请求，同时提取响应头里的延迟信息：
- 在
location中加两行：add_header X-Upstream-Addr $upstream_addr;和add_header X-Upstream-Time $upstream_response_time; - 执行：
for i in {1..20}; do curl -I http://your-domain.com 2>&1 | grep -E "(X-Upstream-Addr|X-Upstream-Time)"; sleep 0.5; done - 输出示例：
X-Upstream-Addr: 192.168.1.11:8080和X-Upstream-Time: 0.027，可快速确认当前路由和延迟
聚合分析识别慢节点
用命令行对日志做简单统计，一眼看出差异：
- 查各节点平均延迟：
awk '{print $12, $13}' /var/log/nginx/upstream.log | awk -F'[" ]' '{if($2 != "-") sum[$2] += $4; cnt[$2]++} END {for (i in sum) print i, sum[i]/cnt[i]}' | sort -k2 -n - 查 P95 延迟（需先排序）：
awk '$13 != "-" {print $13+0}' /var/log/nginx/upstream.log | sort -n | awk 'NR==int(NR*0.95) {print $1}'，再按地址分组跑一次 - 若发现某节点平均延迟明显高于其他（如 0.15s vs 0.03s），且失败次数也多，说明它可能 CPU 过载或磁盘 I/O 阻塞，不是轮询本身的问题
结合监控看趋势更可靠
单次测试容易受瞬时抖动干扰，上线后建议接入基础监控：
- 用
ngx_http_stub_status_module查整体活跃连接与请求速率，判断是否压测充分 - 搭配 Prometheus + Grafana：通过 Lua 模块暴露
$upstream_addr和$upstream_response_time，按地址维度画响应时间热力图或失败率折线图 - 重点盯三个指标：各节点请求数是否接近理论均值、P95 延迟是否稳定、
upstream_addr日志中失败标记（-）是否集中出现在某台
