要实现nginx负载均衡流量的可观测性，需构建闭环链路：启用vts模块获取结构化上游指标，通过nginx-vts-exporter对接prometheus采集关键指标，grafana可视化看板展示流量、响应码、延迟与健康状态，并叠加主动健康检查确保节点状态可信。
要让 Nginx 代理下的负载均衡流量真正“看得见、可分析、能告警”，不能只靠日志翻查或临时命令，得建立一套轻量但闭环的实时可视化链路：从指标采集、结构化暴露，到聚合存储与图形展示。
启用 vts 模块获取结构化上游指标
Nginx 自带的 stub_status 只返回连接数，对负载均衡没实际意义。必须用 nginx-module-vts（Virtual Host Traffic Status）替代：
- 编译时加入
--add-module=/path/to/nginx-module-vts，或直接使用集成该模块的 OpenResty； - 在
http块中开启：vhost_traffic_status on;； - 配置一个专用接口，例如：
location /status/json { vhost_traffic_status_display; vhost_traffic_status_display_format json; allow 127.0.0.1; allow 10.0.0.0/8; deny all; }访问
/status/json就能拿到含upstream.zones、各 server 的requestCounter、inBytes、respCode分布、fails_total等字段的完整 JSON，这才是负载均衡视角下的真实流量快照。
用 nginx-vts-exporter 对接 Prometheus
vts 接口是静态快照，无法追踪趋势或触发响应。需通过 exporter 把它转成 Prometheus 格式：
- 下载并运行
nginx-vts-exporter，指定采集地址：./nginx-vts-exporter -nginx.scrape_uri=http://127.0.0.1/status/json； - 在 Prometheus 的
scrape_configs中添加 job，目标指向 exporter 默认端口9913； - 立即可用的关键指标包括：
-
nginx_vts_upstream_request_total{upstream="backend"}（每秒请求数） -
nginx_vts_upstream_response_time_msec_sum{server="192.168.1.10"}（响应耗时累加） -
nginx_vts_upstream_fails_total（失败计数） -
nginx_vts_upstream_health_check_status（健康状态布尔值）
-
在 Grafana 中构建负载均衡专属看板
Prometheus 存好数据后，Grafana 是最直接的可视化入口：
- 导入社区成熟的 Nginx VTS Dashboard（如 ID 12051），它已预置 upstream 流量分布、响应码热图、各节点延迟对比、失败率趋势等核心面板；
- 手动补充关键视图：
- 按
upstream和server维度拆分的请求速率折线图； -
respCode的饼图 + 时间序列堆叠图，快速定位 5xx 或 4xx 集中节点； - 健康状态（
health_check_status == 1）的实时开关指示器，配合告警规则联动；
- 按
- 设置刷新间隔为 5s 或 10s，确保“实时”不卡顿。
叠加主动健康检查让状态可信
光看流量数字不够，得确认流量是否真发到了活节点上：
- 编译启用
nginx_upstream_check_module； - 在
upstream块中配置：upstream backend { check interval=5 rise=2 fall=3 timeout=1 type=http; check_http_send "GET /health HTTP/1.0\r\n\r\n"; check_http_expect_alive http_2xx; server 192.168.1.10:80; server 192.168.1.11:80; }该模块会把每个 server 的探测结果写入共享内存，vts 模块自动读取并暴露为
check_status字段——Grafana 面板里就能看到“哪个节点刚掉线”，而不是等用户投诉才发觉。
不复杂但容易忽略
