$connection 是 TCP 连接唯一 ID，非并发数，不能反映实时并发；应通过 QPS、$connections_active、请求排队深度及上游耗时等指标分析响应时间波动规律。
直接用 Nginx 或 OpenResty 日志中的 $connection 变量统计并发请求密集度与响应时间的关系，是行不通的——$connection 并非连接数或并发计数器，而是当前 TCP 连接的唯一整型 ID（自增序列号），它本身不反映并发量，也不能直接映射到“同一时刻有多少请求在处理”。想分析服务路径的响应时间波动规律，需另辟路径。
理解 $connection 的真实含义
$connection 是 Nginx 为每个新建立的 TCP 连接分配的内部 ID，从 1 开始递增，重启后重置。它和“并发请求数”无直接关系：一个连接可承载多个 HTTP 请求（HTTP/1.1 keepalive 或 HTTP/2 multiplexing），而高并发下也可能复用少量连接；反之，低并发时连接 ID 仍持续增长。把它当并发指标会得出完全错误的趋势图。
真正可用的并发与负载代理指标
要刻画“请求密集度”，应采集以下可落地、可关联的字段：
-
每秒请求数（QPS）：按时间窗口（如 1s 或 5s）对
$time_iso8601或$msec聚合计数，再与目标路径（$uri）和响应时间（$request_time）关联 -
活跃连接数近似值：用 Nginx 内置变量
$connections_active（需配合 stub_status 模块开启），或通过nginx -T | grep worker_connections结合当前连接状态估算 -
请求排队深度：若使用了限流（limit_req），可记录
$limit_req_status和$limit_req_delay，延迟越长说明瞬时负载越饱和 -
上游等待时间：用
$upstream_connect_time、$upstream_header_time、$upstream_response_time拆分耗时，判断波动来自网络、服务端还是下游依赖
构建路径级响应时间波动分析链路
以 /api/order 为例，推荐做法是：
- 在 log_format 中显式记录：
log_format main '$time_iso8601|$uri|$request_time|$upstream_response_time|$http_x_forwarded_for'; - 用日志采集工具（如 Filebeat + Logstash 或直接用 Loki + Promtail）按分钟级聚合 QPS、P50/P90/P99
$request_time，并打标path=/api/order - 将 QPS 时间序列与响应时间分位数做交叉相关性分析（如 Python pandas.corr 或 Grafana 的 transform → join → correlation panel），识别是否存在显著正相关（QPS↑ → P90↑）及滞后阶数
- 叠加系统指标（CPU、内存、GC pause、DB 连接池等待数）辅助归因：若响应时间上升但上游响应时间稳定，问题大概率在本机资源或应用层线程池争用
轻量级实时观测建议
无需引入完整 APM，也能快速验证规律：
- 写个简单 Bash 脚本，每 10 秒用 awk 统计最近 1 秒内指定路径的平均
$request_time和请求数，输出到 CSV；跑 30 分钟后用 Excel 散点图观察趋势 - 用
goaccess或ngxtop实时看 top uri 的 request_time 分布，配合--group-by='uri' --sort-by='avg_response_time'快速定位敏感路径 - 对关键路径启用 Nginx 的
log_by_lua_block，用 shared dict 计算过去 60 秒内该 URI 的滑动平均响应时间和请求频次，写入 Redis，供告警脚本读取
不复杂但容易忽略：波动规律往往藏在“QPS 阶跃变化”与“响应时间分位数跳变”的时间对齐里，而不是单看某个静态数字。聚焦路径、绑定时间粒度、拆解耗时环节，比执着于一个误用的变量更有效。
