$request_id不能直接当TraceID用，因其为16字节随机字符串，不满足OpenTracing/OpenTelemetry要求的32位十六进制格式，易致采样丢失、链路断裂。
为什么 $request_id 不能直接当 TraceID 用
因为 $request_id 是 Nginx 每次请求生成的 16 字节随机字符串（如 9e4d2a1f4b8c3e7d），不满足 OpenTracing / OpenTelemetry 对 TraceID 的格式要求：必须是 32 位十六进制字符串（128 bit）或 16 字节二进制，且部分 APM 系统（如 Jaeger、SkyWalking）会校验长度和结构。直接透传会导致采样丢失、链路断裂。
实操建议：
- 在 Nginx 中用
map指令将$request_id补零扩展为 32 位：map $request_id $trace_id { ~^(.+)$ "$1$1"; }（利用正则捕获并重复拼接，简单可靠） - 更稳妥的做法是在 upstream 透传时，由第一个业务服务生成标准 TraceID 并回写到响应头，Nginx 仅负责透传
X-Request-ID和traceparent，避免在边缘层做 ID 格式转换 - 若后端已统一使用
spring-cloud-sleuth，需关闭其自动覆盖行为：sleuth.propagation.type=B3并显式读取X-Request-ID作为 fallback
如何让灰度标识随 $request_id 一起透传到下游
灰度发布依赖「染色」——把灰度策略（如 version=v2、user-id=12345）编码进请求上下文，并确保全链路携带。Nginx 本身不解析业务逻辑，所以不能靠 $request_id 推断灰度身份，必须显式注入。
实操建议：
- 在入口 Nginx 配置中，根据请求头、Cookie 或 URL 参数提取灰度标识，存入自定义变量：
set $gray_tag ""; if ($http_x_gray_version != "") { set $gray_tag "v=$http_x_gray_version"; } if ($cookie_gray_user != "") { set $gray_tag "$gray_tag&u=$cookie_gray_user"; } - 将染色信息通过
proxy_set_header注入：proxy_set_header X-Trace-ID $trace_id; proxy_set_header X-Gray-Tag $gray_tag;
（注意：不要塞进traceparent，那是 W3C 标准字段，格式固定） - 下游服务需主动读取
X-Gray-Tag并参与路由决策；若用 Spring Cloud Gateway，可写GlobalFilter解析该 header 并设置ServerWebExchange属性
分布式追踪系统里看不到 Nginx 的 span 怎么办
Nginx 默认不发 span，它不是标准 OpenTracing agent 支持的运行时环境。想让它出现在链路图中，必须借助模块或外部桥接。
实操建议：
- 编译安装
nginx-opentracing模块（官方维护，支持 Jaeger/Zipkin），并在配置中启用：load_module modules/ngx_http_opentracing_module.so; opentracing on; opentracing_trace_locations off; opentracing_jaeger_address 127.0.0.1:6831;
- 不改编译的轻量方案：用
log_format把关键字段（$request_id、$upstream_http_x_trace_id、耗时、状态码）打到 access log，再用 Filebeat + Logstash 做日志关联，补全 Nginx 节点的“伪 span” - 注意
opentracing_jaeger_sampler_type必须设为const或probabilistic，否则默认不采样；且 Nginx 的 span parent_id 来自traceparentheader，务必确认上游已正确传递
灰度流量在链路追踪里被聚合错位或过滤掉了
常见原因是 APM 系统按 Service Name + Operation Name 聚合，而灰度实例往往和基线共用同一个 service name（如 order-service），导致 v1/v2 流量混在一起，无法区分。
实操建议：
- 在 Nginx 向 upstream 转发前，动态改写
X-Service-Name：proxy_set_header X-Service-Name "order-service-gray-$gray_tag";
，下游 SDK 读取该 header 覆盖默认 service name（如 SkyWalking 的agent.service_name可运行时覆盖） - 避免用 URL path 做灰度标识（如
/api/v2/xxx），因为多数 APM 默认把 path 当作 operation name，造成大量离散节点；应统一 operation name（如POST /api/order），靠 tag 区分灰度维度 - Jaeger UI 中若看不到灰度 tag，检查是否启用了 tag 过滤：默认只显示内置 tag，需在
jaeger-query启动参数加--query.ui-tags="X-Gray-Tag,version"
真正难的是灰度规则与 trace 数据的双向对齐——比如你看到某条慢链路打了 v2 标签，但不确定它是被哪条灰度路由规则匹配的。这时候得把 Nginx 的 access_log 和 tracing 的 span log 按 $request_id 关联查，而不是只盯 UI。
