Nginx通过$request_id实现全链路日志追踪：自动或继承X-Request-ID头，proxy_set_header透传，log_format中嵌入该变量，并要求下游服务统一读取、记录和转发该ID。
在微服务架构中，通过 log_format 在 Nginx 中注入 $request_id，是实现前端请求到后端服务全链路日志追踪的关键一环。它让一次用户请求在 Nginx、网关、业务服务、中间件等各环节产生的日志，都能通过同一个唯一 ID 关联起来。
确保 $request_id 在请求生命周期中稳定传递
Nginx 自带的 $request_id 变量（需 1.11.0+）会在每个新请求进入时自动生成一个 UUID v4 格式的字符串。但前提是：该请求未携带 X-Request-ID 头，否则 Nginx 会直接复用该值——这是实现跨服务透传的基础逻辑。
- 若上游（如浏览器或 API 客户端）已发起了带
X-Request-ID的请求，Nginx 会继承它，避免覆盖； - 若无此头，Nginx 自动生成并设置响应头
X-Request-ID，同时可用于日志记录； - 务必在
proxy_pass前启用proxy_set_header X-Request-ID $request_id;，确保下游服务也能收到该 ID。
在 log_format 中嵌入 $request_id 并输出到访问日志
定义日志格式时，将 $request_id 作为固定字段插入，便于后续用日志系统（如 ELK、Loki）提取和关联。
log_format main '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'$request_id ' # ← 关键：显式加入
'$upstream_http_x_request_id '; # ← 可选：记录下游返回的 ID（用于验证透传）然后在 access_log 中使用该格式：
access_log /var/log/nginx/access.log main;
下游服务需主动读取并注入自身日志
Nginx 的 $request_id 只解决入口层打标问题。要形成完整链路，所有微服务必须：
- 从 HTTP 请求头
X-Request-ID中读取该值（而非自行生成）； - 在应用日志中将该 ID 作为固定字段输出（如 Logback 的
%X{X-Request-ID}或 Zap 的With(zap.String("request_id", rid))）； - 调用其他服务时，通过
proxy_set_header X-Request-ID $request_id;或代码中透传该 header，保持链条不断。
验证与排查常见断点
链路断裂往往发生在边界处。可快速检查以下几点：
- 确认 Nginx 版本 ≥ 1.11.0，并启用
underscores_in_headers on;（若自定义 header 含下划线）； - 用
curl -H "X-Request-ID: abc123" http://your-api/测试透传是否生效； - 查看 Nginx access log 是否出现 request_id 字段，且与下游服务日志中的 ID 一致；
- 注意某些框架（如 Spring Cloud Gateway）默认不透传
X-Request-ID，需显式配置允许转发。
不复杂但容易忽略：只要 Nginx 正确生成/透传、下游服务统一消费、日志格式对齐，全链路 ID 就能自然贯穿整个调用路径。
