nginx全路径响应时间追踪需组合$request_time（端到端总耗时）、$upstream_response_time和$upstream_connect_time等变量，并配合自定义日志格式与可选模块实现；$request_time包含upstream处理及nginx自身处理，但不含tcp建连前延迟。
在 Nginx 中实现全路径响应时间追踪，核心是记录从请求进入 Nginx 到响应返回客户端的完整耗时，包括 upstream 处理、Nginx 自身处理（如 rewrite、proxy、gzip）等所有环节。这不是单靠 $request_time 就能覆盖的，需组合多个内置变量并配合日志格式与可选模块。
使用 $request_time 记录端到端总耗时
$request_time 是最常用且最可靠的变量，表示从接收到客户端第一个字节开始，到向客户端发送完最后一个字节为止的总时间（单位：秒，精度为毫秒）。它已包含 DNS 解析（若发生在 Nginx）、upstream 建连、后端处理、Nginx 本体处理等全部阶段。
- 该变量在日志写入时才计算完成，不能用于条件判断或 header 设置
- 注意：它不包含 TCP 连接建立前的网络延迟（如 SYN 握手），但包含 SSL/TLS 握手耗时（若启用 HTTPS）
- 建议在
log_format中以毫秒精度输出：'$request_time' → '$request_time' 保留 3 位小数
拆解关键子阶段：用 $upstream_response_time + $upstream_connect_time
当需要定位瓶颈是否出在上游服务，可结合以下变量分析：
-
$upstream_connect_time：Nginx 与 upstream 建立连接所花时间（含 DNS 查询、TCP 握手、TLS 握手） -
$upstream_header_time：从发送请求到收到 upstream 第一个字节的时间（即「首字节时间」，含网络传输+后端逻辑） -
$upstream_response_time：从发送请求到接收完 upstream 全部响应的时间（即「总响应时间」） - 多个 upstream（如负载均衡）会以逗号分隔，例如
"0.002, 0.005"；取第一个值通常代表本次实际使用的节点
通过对比 $request_time 与 $upstream_response_time 差值，可初步判断 Nginx 本体处理（如 proxy_buffer、gzip、add_header）是否引入显著开销。
记录 Nginx 内部处理耗时（需启用 ngx_http_log_module 的高级支持）
Nginx 默认不暴露 rewrite、access、log 阶段的细分耗时，但可通过以下方式增强可观测性：
- 启用
log_subrequest on可记录内部子请求（如 auth_request、include 指令触发的请求），便于排查鉴权/重定向链路延迟 - 使用
ngx_http_realip_module和X-Real-IP等头，确保$remote_addr准确，避免因代理导致的 IP 误判影响统计归因 - 对关键 location 块添加
access_log ... main并自定义 log_format，将$time_iso8601、$status、$body_bytes_sent与耗时变量一并输出，方便后续按路径聚合分析
进阶：用 OpenTelemetry 或第三方模块做分布式追踪
若需跨服务链路追踪（如 Nginx → API Gateway → Backend → DB），仅靠日志变量不够，需引入上下文传播：
- 通过
proxy_set_header X-Request-ID $request_id透传唯一请求 ID，配合后端服务统一埋点 - 使用 zipkin-opentracing 或 nginx-opentracing 模块，在 Nginx 层自动注入 trace_id/span_id，并上报至 Jaeger/Zipkin
- 注意：这些模块需重新编译 Nginx 或使用 OpenResty 发行版，生产环境启用前应压测验证性能影响
不复杂但容易忽略的是时间精度与日志采样——高频接口建议对 $request_time > 1.0 的慢请求单独记录详细 trace，避免日志爆炸。
