通过access_log中$upstream_addr字段高频采样统计Nginx加权轮询各节点流量占比，并用error_log交叉验证健康状态；需在nginx.conf中自定义log_format显式包含$upstream_addr和$upstream_response_time，日志写入upstream_trend.log，可用head/tail分析最近10分钟波动。
监控Nginx加权轮询各节点的实时流量占比，关键不是“实时秒级刷新”，而是通过access_log中$upstream_addr字段做高频采样统计，再结合error_log交叉验证健康状态。不需要额外部署Agent或改用商业版，标准开源Nginx就能做到准实时判断。
确保日志包含可识别后端的关键字段
默认log_format不记录转发到哪台后端，必须显式加入$upstream_addr（实际目标地址）和可选的$upstream_response_time（响应耗时）：
- 编辑nginx.conf，在http块内定义日志格式，例如：
log_format upstream_log '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
' "$upstream_addr" "$upstream_response_time";
- 在server或location块中启用该格式：access_log /var/log/nginx/access.log upstream_log;
- 重载配置：nginx -s reload，确认新日志行末尾出现类似"192.168.1.10:8080" "0.023"的内容
用命令行快速抽样统计当前占比
对最新日志片段执行字段提取+频次统计，5秒内出结果：
- 统计最近1万行中各后端出现次数（假设$upstream_addr是第12列）：
tail -10000 /var/log/nginx/access.log | awk '{print $12}' | sort | uniq -c | sort -nr
- 若权重配比为weight=3 : weight=2 : weight=1，理论应接近50% : 33% : 17%
- 发现某节点占比持续低于权重（如weight=3只占25%），说明它可能被自动剔除，需查error.log
同步检查error_log识别隐性失联
流量占比异常往往不是配置问题，而是节点已被Nginx临时下线——这不会在access_log里体现，但会留在error.log中：
- 高频检查超时与失联报错：
grep -E 'upstream timed out|no live upstreams|connect() failed' /var/log/nginx/error.log | tail -15
- 看到大量upstream timed out (110)，说明该节点响应慢或网络不通，Nginx已触发max_fails机制将其移出轮询队列
- 此时即使配置了weight=3，实际流量也为0；修复节点后需等fail_timeout时间才会自动恢复
进阶：用脚本实现分钟级趋势观察
把上面逻辑封装成简单脚本，每分钟运行一次并输出对比：
- 新建/usr/local/bin/check_upstream.sh，内容含tail+awk+grep组合
- 用crontab每分钟执行：* * * * * /usr/local/bin/check_upstream.sh >> /var/log/nginx/upstream_trend.log
- 后续可用head/tail快速查看最近10分钟各节点占比波动，无需图形化工具
