nginx全链路追踪需稳定生成并透传$request_id：1.11.0+直接使用内置变量；proxy_set_header须在location内紧邻proxy_pass；日志中显式记录$request_id；后端须读取x-request-id；对接jaeger/otel需专用模块及配置。
实现 Nginx 代理下的全链路分布式追踪，核心不是“加一个 ID 就完事”，而是让同一个请求标识（如 $request_id）从入口开始稳定生成、全程透传、统一记录、跨服务对齐。它不依赖复杂 SDK，但对配置细节极其敏感——错一处，链路就断。
确保 $request_id 稳定生成并唯一可用
Nginx 1.11.0+ 内置 $request_id，每次请求进入自动生成 32 位十六进制字符串（如 a1b2c3d4e5f678901234567890abcdef），无需模块、无需 Lua。关键操作：
- 执行 nginx -v 确认版本 ≥ 1.11.0；低于此版本必须升级，不可用 map 或 random 模拟替代
- 不要在 http 或 server 块顶层写
set $req_id $request_id—— 它天然存在，直接引用即可 - 避免在多个 location 中重复
set或覆盖，尤其当上游已是网关时，应优先复用已传入的 X-Request-ID
透传 request_id 到后端服务
proxy_set_header X-Request-ID $request_id 必须放在 location 块内，且紧邻 proxy_pass，否则无效：
- 错误示例：
http { proxy_set_header X-Request-ID $request_id; }→ 不生效 - 正确示例：
location /api { proxy_set_header X-Request-ID $request_id; proxy_pass http://backend; } - 若使用 Kubernetes nginx-ingress，需确认版本 ≥ 1.9，并添加 annotation
enable-request-id: "true" - 后端服务（Spring Boot/Go/Node.js）必须主动读取该 header，并注入 MDC、context 或日志结构体，不能忽略或重新生成
把 request_id 写进 Nginx 日志并标准化字段名
log_format 中必须显式包含 $request_id，而非依赖 $http_x_request_id（它来自客户端，可能为空或被篡改）：
- 推荐格式：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" req_id:"$request_id"'; - 引号包裹
"$request_id"可防止 Logstash grok 解析时截断或误判 - ELK 场景下，Filebeat 或 Logstash 需提取该字段为统一 key（如
trace_id），并映射为 Elasticsearch 的 keyword 类型 - 所有下游服务日志中，该字段名、格式、长度必须严格一致（例如都叫
trace_id，值为 32 位小写 hex）
与 Jaeger / OpenTelemetry 等专业追踪系统协同
仅靠 $request_id 支持日志串联，但若要接入 Jaeger、Zipkin 或 OTel 后端，需额外桥接：
- 不能只透传
X-Request-ID—— Jaeger SDK 默认不识别它；必须用 nginx-opentracing（v0.9+）或 opentelemetry-nginx-module - 启用插件后，需显式配置：
ot_tracer inject_request_id on;和ot_tracer operation_name "nginx_gateway" - opentelemetry-nginx-module 还需设置：
otel_propagators "tracecontext,baggage"，否则$request_id不会注入为traceparent - 所有中间 Nginx 层（含 stream 模块、ALB 后的 Nginx）必须支持 HTTP header 透传，否则
X-Request-ID根本到不了下一跳
