监控并发需分层：Nginx应用层用stub_status取Active connections；VTS模块适配多虚拟主机，需jq计算active+waiting；系统层用ss查ESTABLISHED连接；数据库层盯HikariCP的connections.active及pending指标。
直接抓取 active_connections 并发指标，关键不是“采集哪个数字”，而是明确你要监控的是哪一层的并发——是 Nginx 应用层的真实处理连接，还是系统 TCP 层的已建立连接，或是数据库连接池的活跃会话。不同场景对应不同数据源、不同采集方式，不能混用。
一、Nginx 应用层 active connections（最常用）
这是 Web 服务真正正在处理请求的连接数，含 reading/writing/waiting，不包含 TIME_WAIT 或半开连接。
- 前提：启用
ngx_http_stub_status_module，配置如下：
location /nginx_status {
stub_status on;
access_log off;
allow 127.0.0.1;
deny all;
}
- 采集命令（推荐每 2–5 秒执行一次）：
curl -s http://127.0.0.1/nginx_status | awk '/Active connections/ {print $3}'
- 若需对接 Prometheus：用 nginx-prometheus-exporter，它会自动解析 stub_status 输出并暴露为
nginx_connections_active指标 - 注意：别用
netstat -an | grep :80 | wc -l，它会把 LISTEN、TIME_WAIT、CLOSE_WAIT 全算进去，结果严重失真
二、Nginx VTS 模块的 connections.active + waiting（适合多虚拟主机/上游）
VTS 提供更细粒度的 per-server 或 per-upstream 连接统计，但 raw active 值有局限——它不含 listen backlog 和半开连接。
- 安全提取方式（用 jq）：
curl -s http://127.0.0.1:8080/status | jq -r '.nginx.connections.active + .nginx.connections.waiting'
- 建议做滑动窗口判断：连续 5 次采样中，均值 > 阈值 × 1.3 且最大值 > 阈值 × 1.8 才触发告警，避免毛刺误报
- 配合内核指标一起看：/proc/net/softnet_stat 第 1 列（drop）突增 + SyncookiesSent 上升，说明可能遭遇 SYN 洪泛，此时 VTS 数值可能还很低
三、Linux 系统层 TCP 并发连接（看 ESTABLISHED 总量）
适用于排查整体网络连接压力，尤其在 Windows 用性能监视器或 Linux 用 ss 命令时。
- 精准查看 80/443 端口 ESTABLISHED 连接数：
sudo ss -tn state established '( dport = :80 or dport = :443 )' | wc -l
- 对比原则：该值应略高于 stub_status 的 Active connections（因 reading 连接也属 ESTABLISHED）；若相差超 10%，需检查 keepalive_timeout、client_header_timeout 是否过长，或后端响应是否卡顿
- Windows 用户：直接打开 perfmon → 添加计数器 → TCPv4\Connections Established，采样间隔设为 3 秒即可
四、数据库连接池活跃连接（如 HikariCP、Druid）
Web 服务并发高，不一定代表 DB 层压力大；但 DB 连接池耗尽会直接导致请求阻塞，必须单独监控。
- HikariCP（Spring Boot + dynamic-datasource）暴露指标：
hikaricp.connections.active - 通过 Actuator Endpoint 查看：
GET /actuator/metrics/hikaricp.connections.active - 或用 Micrometer + Prometheus，查询表达式：
hikaricp_connections_active{application="myapp"} - 重点盯
pending指标：非零表示线程在排队等连接，是连接池瓶颈的早期信号
