利用 Nginx 变量 $request_id 配合 ELK 栈构建跨系统的分布式链路追踪-Nginx-PHP中文网

Nginx $request_id（1.11.0+内置32位十六进制字符串）作为全链路唯一标识，通过proxy_set_header透传、access_log记录、后端MDC注入、Logstash结构化解析及Kibana跨服务关联查询，实现低成本、非侵入式分布式链路追踪。

利用 nginx 变量 $request_id 配合 elk 栈构建跨系统的分布式链路追踪

利用 Nginx 的 $request_id 变量配合 ELK（Elasticsearch、Logstash、Kibana）构建分布式链路追踪，核心在于统一请求标识贯穿全链路，并在各环节日志中透传和记录该 ID。关键不在于替换现有链路系统，而是低成本补全边缘层（如反向代理层）的追踪上下文。

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

下游服务（如 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 负责从 Nginx access log 和各服务日志中提取 request_id，并补全元数据以支持关联分析：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

使用 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 中，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（需在应用端将两者绑定），实现代码级性能下钻