需在Nginx中配置含$upstream_status和$upstream_addr的专用日志格式，并结合$upstream_cache_status区分缓存与回源，再通过awk按节点+状态码+响应时间聚合分析，精准定位异常存储节点。
要统计静态存储节点的健康分布，核心是把 $upstream_status 和具体节点地址绑定起来分析，不能只看整体错误率——因为某台机器可能高频返回 500，而其他节点完全正常，全局平均会掩盖风险。
必须记录带节点标识的 upstream_status 日志
默认 access_log 不包含上游状态和地址。需在 http 块中定义专用日志格式：
log_format storage_log '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent $upstream_status $upstream_addr ' '$upstream_response_time "$http_referer" "$http_user_agent"';
并在静态资源 location 中启用：
access_log /var/log/nginx/storage.log storage_log;
重启 Nginx 后，每条日志都会明确写出请求落到哪台存储节点、返回什么状态码、耗时多少。
按节点 + 状态码聚合识别异常模式
用 awk 快速定位问题节点和典型错误：
- 查各节点的 4xx/5xx 分布（谁错得多）：
awk '{print $7, $8}' /var/log/nginx/storage.log | grep "^[45]" | sort | uniq -c | sort -nr - 单独统计每个节点的失败次数（排除重试干扰）：
awk '$7 ~ /^[45]/ {print $8}' /var/log/nginx/storage.log | sort | uniq -c | sort -nr - 注意：若 $8 字段含多个地址（如 10.0.3.10:80,10.0.3.11:80），说明发生重试，两个节点都应纳入排查范围
结合响应时间判断是节点故障还是瞬时抖动
单看状态码不够——504 可能是超时，502 可能是连接失败，200 但响应时间 >2s 则说明节点已卡顿。
- 筛选慢响应且状态异常的请求：
awk '$7 ~ /^[45]/ && $9 > 1.0 {print $8, $7, $9}' /var/log/nginx/storage.log - 对比同一节点下 200 与非 200 请求的 $upstream_response_time 中位数，差距大说明该节点存在性能退化
- 若某节点长期出现 “-”（空 upstream_status），说明 Nginx 根本没转发请求过去，可能是 upstream 配置失效或全部标记为 down
区分缓存层与后端存储的真实责任
静态资源常走 proxy_cache，$upstream_status 只反映缓存未命中后回源的结果。要避免误判：
- 加 $upstream_cache_status 到日志，确认请求是否真的打到了后端：
log_format storage_log '... $upstream_cache_status $upstream_status $upstream_addr'; - 若大量请求 cache_status=MISS 但 upstream_status=500，才是后端存储真实故障；
若 cache_status=HIT 占比高，而 upstream_status 异常少，则问题不在存储节点本身 - 对 CDN 或多级缓存架构，需逐层检查对应 upstream 的 $upstream_status，不能只盯最后一跳
