$connection 不适合衡量并发密集度，因其仅为单调递增的TCP连接序号，不反映活跃连接数、请求堆积或资源竞争状态。
直接利用 Nginx 日志中的 $connection 变量无法统计并发请求密集度与响应时间的波动规律——因为 $connection 是一个**连接序号（单调递增的整数）**，不是并发计数器，也不反映当前活跃连接数或请求堆积状态。
为什么 $connection 不适合衡量并发密集度
$connection 在 Nginx 中表示该请求所属 TCP 连接被 Nginx 接受时分配的唯一序号（从 1 开始递增），它不随连接复用、请求并发而重置或变化。例如：
- 同一个 HTTP/1.1 Keep-Alive 连接上发出 10 个请求，
$connection值完全相同； - 不同客户端的两个并发请求，可能拥有相邻但无关的
$connection值（如 12345 和 12346），无法说明它们是否“同时到达”或“竞争资源”； - 它不体现服务端当前处理中的请求数、队列长度或线程/进程负载。
真正可用于分析并发影响的替代日志变量
要建模“并发请求密集度 → 单路径响应时间波动”，需采集能反映**瞬时服务压力**和**路径级耗时**的指标：
-
$request_time：完整请求处理时间（秒，含排队、网络接收、后端交互、发送响应），是核心因变量； -
$upstream_response_time（如有代理）：后端真实处理耗时，可分离网关开销； -
$connections_active+$connections_reading+$connections_writing：通过 stub_status 模块暴露的实时连接状态，需配合定时采样（非每条日志）； - 自定义并发上下文：在应用层（如 Lua 或后端服务）注入
$sent_http_x_concurrent_hint等头，记录当前服务实例的活跃请求数（需应用支持）； - 外部指标对齐：用 Prometheus 抓取
nginx_connections_active或应用 metrics（如http_server_requests_seconds_count{uri="/api/safe"}），按秒级聚合后与日志按时间窗口关联。
实操建议：构建波动归因分析链
以安全服务路径（如 /api/v1/auth/verify）为例：
- 增强 Nginx 日志格式，固定记录：
log_format secure_log '$time_iso8601|$remote_addr|$request|$status|$request_time|$upstream_response_time|$http_user_agent|$uri'; - 按分钟切分日志，用脚本（如 Python + Pandas）统计每分钟内该路径的：
• 请求总数
• P90/P95$request_time
• 平均并发估算值（可用该分钟内$request_time总和 ÷ 60 秒，粗略反映平均并发负载）； - 将分钟级结果与同一时段 Prometheus 中的
process_cpu_seconds_total、go_goroutines（Go 服务）或tomcat_threads_busy（Java）等指标做时序相关性分析（如皮尔逊系数）； - 识别拐点：当并发请求密度（如每秒请求数 > 50）持续 3 分钟，且
$request_timeP95 上升 > 200%，再检查对应时刻后端错误率、GC pause 或 DB 连接池等待是否同步激增。
关键结论
想发现“并发密集度→响应波动”的规律，必须放弃 $connection，转而结合：
• 路径粒度的 $request_time 和 $upstream_response_time；
• 外部采集的实时资源指标；
• 时间对齐的聚合分析方法。
否则仅靠连接序号，得到的只是编号分布，不是并发真相。
