Nginx $request_id（1.11.0+内置32位十六进制字符串）作为全链路唯一标识，通过proxy_set_header透传、access_log记录、后端MDC注入、Logstash结构化解析及Kibana跨服务关联查询，实现低成本、非侵入式分布式链路追踪。
利用 Nginx 的 $request_id 变量配合 ELK（Elasticsearch、Logstash、Kibana）构建分布式链路追踪，核心在于统一请求标识贯穿全链路，并在各环节日志中透传和记录该 ID。关键不在于替换现有链路系统，而是低成本补全边缘层（如反向代理层）的追踪上下文。
确保 $request_id 在 Nginx 中稳定生成与透传
Nginx 默认不自动设置 $request_id，需显式启用或生成：
- 使用
ngx_http_core_module提供的内置变量$request_id（Nginx 1.11.0+），它会在每个请求进入时自动生成唯一 UUID v4 字符串；若版本较低，可用map+random或第三方模块（如nginx-http-random-index-module）模拟，但推荐升级 Nginx - 在
http或server块中，通过proxy_set_header X-Request-ID $request_id;将其作为 HTTP 头透传给后端服务，确保下游应用能读取并复用 - 同时建议在 access_log 中显式记录：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$http_x_request_id" $request_id';，避免依赖$http_x_request_id（可能为空）而直接落盘 Nginx 自身生成的$request_id
后端服务适配：复用并注入 request_id 到业务日志
下游服务（如 Spring Boot、Node.js、Go）无需重生成 ID，应优先从 X-Request-ID 请求头提取，并将其注入应用日志上下文：
- Spring Boot 可借助
logback-spring.xml配合MDC：在 Filter 中MDC.put("requestId", request.getHeader("X-Request-ID"))，并在 logback pattern 中添加%X{requestId} - Node.js（Express）可用
express-mung或中间件提取 header 并挂载到res.locals，再由 winston/pino 等日志库通过 context 注入 - Go（net/http）可封装 Handler，在 ServeHTTP 中解析 header 并传入日志字段，例如用
zerolog.With().Str("request_id", req.Header.Get("X-Request-ID")).Logger() - 重点：所有异步调用（RPC、MQ 生产/消费、DB 操作日志）都应携带该 ID，形成完整调用脉络
Logstash 日志采集与结构化增强
Logstash 负责从 Nginx access log 和各服务日志中提取 request_id，并补全元数据以支持关联分析：
- 使用
grok过滤器精准提取 Nginx access log 中的$request_id字段（注意匹配 UUID 格式：[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}） - 对应用日志，若已结构化（如 JSON 格式），用
json过滤器解析；若为文本，同样用 grok 提取request_id字段 - 统一添加字段：如
service_name（通过文件路径或主机名推断）、log_type（"nginx_access" / "app_error" / "app_info"）、timestamp（确保时区一致，推荐 UTC） - 可选增强：用
dissect或kv提取 URL 参数、响应时间、状态码等，便于后续聚合分析
Kibana 中实现跨系统链路可视化与诊断
在 Kibana 中，request_id 是串联 Nginx 与各微服务日志的唯一主键：
- 创建 Discover 页面时，将
request_id设为筛选条件，即可一键查看某次请求经过 Nginx、API 网关、用户服务、订单服务、数据库访问的全部日志事件 - 利用 Lens 或 Dashboard 构建“请求耗时分布”图表：按
request_id分组，取最大timestamp减最小timestamp得端到端延迟；叠加service_name维度，识别慢服务节点 - 配置 Alerting：当某
request_id对应的日志中同时出现status: 5xx和log_level: "ERROR"，触发告警并附带完整日志上下文链接 - 进阶技巧：结合 APM Server（如 Elastic APM）采集的 span 数据，用
trace.id关联request_id（需在应用端将两者绑定），实现代码级性能下钻
这套方案不依赖侵入式 SDK，适合已有 Nginx + ELK 基础设施的团队快速落地。难点不在技术实现，而在日志规范统一与上下游协同——只要 request_id 从入口到出口不丢失、不篡改、不重复，链路就立得住。
