如何用Nginx和VTS模块构建基于Upstream的实时流量看板长尾词？

本文共计1060个文字，预计阅读时间需要5分钟。

直接输出结论：

确认 Nginx 是否已启用 vts 模块

很多人卡在第一步——以为装了 vts 就能用，其实模块没加载等于白搭。最直接的验证方式是检查 Nginx 启动时的模块列表：

• 执行 nginx -V 2>&1 | grep -o with-http-vts-module，有输出才说明编译时加了该模块
• 若无输出，即使你下载了 vts 源码、跑了 ./configure --add-module=...，也极可能漏掉了 make install 或覆盖了旧二进制，需重新部署 nginx 可执行文件
• 运行中验证：访问 /status/format/json（如 curl http://localhost/status/format/json），返回 404 表示 location 未配置；返回 JSON 但 upstreams 字段为空，说明 server 块里没定义 upstream 或未被任何 proxy_pass 引用

配置 vts status 接口并限制访问范围

location /status 是数据出口，但默认开放会带来安全与性能风险。务必显式控制：

• 用 allow/deny 限定 IP，例如只允许内网监控系统访问：allow 192.168.10.0/24; deny all;
• 避免放在 server 块顶层，应置于一个独立、无业务逻辑的 server 中（比如监听 127.0.0.1:8080），防止被外部直接探测到
• 不要省略 vhost_traffic_status off; 在非统计 server 块中关闭，否则每个虚拟主机都会记录自身流量，干扰 upstream 维度聚合
• JSON 格式接口路径固定为 /status/format/json，不要试图改写 URI，vts 不支持自定义 endpoint

让 upstream 流量真正进入 vts 统计管道

vts 只统计被 proxy_pass 显式转发到 upstream 的请求，且该 upstream 必须有名字（不能是 IP 直连）。常见断点在这里：

• 确保 upstream 定义在 http 块下，而非 server 内；名称要和 proxy_pass http://your_upstream_name 中的一致
• 如果用了 proxy_pass 后跟变量（如 proxy_pass http://$backend），vts 无法解析变量值，对应 upstream 将不会出现在 /status/format/json 的 upstreams 列表中
• 健康检查（health_check）本身不产生统计计数，但会影响 down 状态标记；只有真实客户端请求经过 proxy_pass 才会计入 requestCounter、inBytes 等字段
• 注意：vts 对 WebSocket 连接仅统计建立次数（requestCounter），不统计后续帧流量，如需带宽维度需额外抓包或日志分析

前端看板读取与解析 upstream 数据的关键字段

从 /status/format/json 返回的 JSON 中，upstreams 是对象，key 为 upstream 名，value 包含实时指标。重点盯这几个字段：

• requestCounter：总请求数（含 5xx，不是成功数）
• inBytes/outBytes：累计出入流量字节数，可用于计算带宽趋势，但注意单位是字节，不是 KB/MB
• responseMsec：所有请求响应时间总和（毫秒），除以 requestCounter 得平均值；vts 不提供 P95/P99，需前端自行聚合
• responses.2xx、responses.5xx 等：各状态码计数，用于故障率告警；注意 responses.total 应等于 requestCounter，不等说明有连接中断或超时未计入
• 动态 upstream（如通过 resolver + 变量实现的服务发现）不会出现在此 JSON 中，vts 仅支持静态命名 upstream

真正难的是把 JSON 里的数字变成可操作的信号——比如 5xx 突增 3 倍持续 60 秒，这个判断逻辑不在 Nginx 里，得靠外部系统拉取、缓存、比对。vts 只管“报数”，不管“报警”。