nginx error_log不记录权重动态变更，真正监控需依赖/status接口比对、外部模块notice日志（如nginx-upstream-dynamic或upsync-module）及reload前后的配置快照比对，实现变更可观测。
Nginx 的 error_log 本身不记录后端节点权重的动态变更——权重（weight）是静态配置项，修改后需 reload 或通过外部模块热更新，而 error_log 的 notice 级别仅反映进程动作（如 worker 启动），不体现 upstream 节点权重变化。
真正能“监控权重变更”的，不是靠 error_log 解析，而是靠变更源头的可观测性 + 状态接口比对 + 日志辅助验证。以下是实用路径：
用 /status 接口对比前后状态（最直接）
- 启用
nginx-module-vts或nginx-upstream-check-module的check_status指令，暴露 JSON 格式节点状态：location /status { vhost_traffic_status_display; vhost_traffic_status_display_format json; } - 该接口返回每个 server 的
weight（配置值）、req_counter、fails、down等字段。 - 用脚本定时抓取（如
curl http://localhost/status/format/json），提取upstream.zones[].server[].weight，与上一版本比对。 - 发现差异时，记录时间戳、节点 IP、旧/新权重，并写入独立审计日志或触发告警。
让外部调权操作留下可追踪痕迹
如果你用的是支持热更新的模块（如 nginx-upstream-dynamic 或 nginx-upsync-module），它们本身会输出操作日志：
-
nginx-upstream-dynamic：启用log_notices on;后，在error_log notice中会出现类似：[notice] upstream server 192.168.1.10:8080 weight changed from 3 to 5
-
nginx-upsync-module（配合 Consul）：在 Consul KV 更新时，Nginx 拉取日志中会有：[notice] upstream sync from consul: backend updated, 2 servers changed
⚠️ 前提：这些日志需显式开启对应模块的 notice 级别输出，且 Nginx 编译时已集成该模块。
利用 error_log 的 notice 作为间接信号（仅限 reload 场景）
如果权重变更靠 nginx -s reload 实现（非热更新），error_log notice 会输出：
[notice] 12345#0: signal process started [notice] 12346#0: starting worker processes
这表示新配置（含新权重）已加载，但无法知道具体哪台节点权重变了。可配合以下方式增强可追溯性：
- 在 reload 前，用脚本备份当前 upstream 配置片段并打时间戳；
- reload 后立即调用
/status接口快照，与备份比对； - 将 reload 操作本身纳入部署流水线（如 Ansible 的
notify: reload nginx），在日志中写入变更摘要。
不推荐依赖 access_log 或 $upstream_addr 推断权重变化
- 请求分发比例受
weight、least_conn、失败剔除、重试策略共同影响，短期统计波动大； - 即使某节点权重翻倍，也可能因响应慢被
least_conn绕过，导致实际流量未明显上升； - 仅靠日志采样反推权重，误差高、延迟大，不适合作为监控依据。
权重变更监控的本质，是把“配置动作”和“运行时状态”打通。核心不在 error_log 里找线索，而在主动采集状态、绑定变更上下文、建立版本比对机制。
