vts的connections.active不可靠，因不包含listen backlog队列及半开连接；应监控active+waiting，并结合/proc/net/softnet_stat drop与syncookiessent判断syn洪泛或丢包。
为什么直接用Nginx VTS的connections指标不可靠
很多人以为从VTS JSON接口（如 /status/format/json）里读取 connections.active 就能监控并发连接异常，但实际会漏掉关键问题：这个值是Nginx worker进程内瞬时统计，不包含已进入accept队列但尚未被worker取走的连接（即 listen backlog 队列），也不反映TIME_WAIT、SYN_RECV等半开连接。当突发SYN洪泛或慢速攻击发生时，connections.active 可能还很低，但系统早已卡死。
真正需要盯的是两个协同指标：
-
connections.active+connections.waiting—— 表示当前真正被Nginx持有连接数 - Linux内核的
/proc/net/softnet_stat第1列（drop计数）和/proc/net/snmp中TcpExt:行的SyncookiesSent—— 判断是否触发了SYN Cookie或软中断丢包
如何从VTS JSON中安全提取并发连接数据并防抖
VTS模块本身不提供告警能力，必须外接采集器。常见错误是用curl轮询 /status/format/json 并直接比较原始值，结果被worker重载、reload或短连接抖动干扰，误报率极高。
实操建议：
- 采集频率设为
2s间隔，单次采集超时严格控制在500ms（加--max-time 0.5），避免阻塞后续轮询 - 解析时只取
nginx.connections.active和nginx.connections.waiting字段，忽略accepted/handled等累计值 - 做滑动窗口计算：连续5次采样中，若
active + waiting的均值 > 阈值 × 1.3 且最大值 > 阈值 × 1.8，才触发初筛（防单点毛刺） - 用
jq -r '.nginx.connections.active + .nginx.connections.waiting'提取，别用Python json.load() 再算——多一次解析就多一次延迟风险
怎样把VTS数据对接到Prometheus并设置合理告警规则
VTS官方只提供JSON输出，没有原生Prometheus格式。硬改源码或加中间层（如vts-exporter）容易引入单点故障，更稳的方式是用 textfile_collector + 定时脚本。
操作要点：
- 写一个
/var/lib/node_exporter/vts.prom文件，每10秒由脚本更新一次，内容形如：nginx_vts_connections_active 127<br>nginx_vts_connections_waiting 8
- 在Prometheus中配置
textfile_collector目录，并加job拉取node_exporter的/metrics - 告警规则别只写
nginx_vts_connections_active > 1000，应组合判断：avg_over_time(nginx_vts_connections_active[2m]) > 800<br>and<br>rate(node_network_receive_drop_total{device="eth0"}[1m]) > 0.1——双条件同时满足才发告警
为什么阈值不能按“服务器CPU核数×1000”粗略估算
这是最常踩的坑。VTS显示的并发连接数和系统真实负载不是线性关系。一个HTTP/2长连接可能复用几十个请求，而1000个HTTP/1.1短连接每秒新建200次，对event loop的压力远高于前者。
真正该参考的是：
- Nginx配置中
worker_connections值（默认512），告警阈值建议设为该值的70%~85%，而非物理资源上限 - 观察
nginx.connections.idle占比：若长期，说明连接复用差或客户端异常保活，此时即使总数不高也要预警 - 检查
net.core.somaxconn和net.ipv4.tcp_max_syn_backlog是否匹配——如果VTS显示等待连接少但ss -s显示SYN-RECV大量堆积，说明内核backlog已满，VTS根本看不到这部分
复杂点在于：VTS本身不暴露连接生命周期分布，你得配合 ss -i 或 eBPF 工具看 RTT、retransmit 情况，否则所谓“异常并发”可能只是下游服务响应变慢导致的连接滞留。
