$request_id是全链路日志追踪的起点，需在Nginx中显式写入access_log并透传X-Request-ID头至后端，各服务须统一接收、记录并继续传递该ID，才能通过日志平台按ID聚合还原完整调用链。
直接用 $request_id 就能串起一次请求在所有服务节点上的完整日志，是排查用户投诉最高效的方式。
确认 $request_id 已正确注入并透传
这是前提。Nginx 默认支持 $request_id 变量（需启用 ngx_http_core_module），但必须确保它被写入 access_log，并且下游所有服务（如 API 网关、微服务、DB 代理）都接收并复用该 ID，而不是生成新 ID。
- Nginx 配置示例：log_format main '$request_id - $remote_addr - [$time_local] "$request" $status $body_bytes_sent';
- 后端服务需从 HTTP Header（如 X-Request-ID）中读取该值，并在自身日志、调用下游时继续透传
- 检查一次请求的响应 Header 是否返回了 X-Request-ID，且与 Nginx access log 中的 $request_id 一致
在各组件日志中统一检索该 ID
拿到用户投诉对应的 $request_id 后，在所有相关系统的日志中并行搜索，就能还原整条链路。
- Nginx access/error log：确认请求是否到达、状态码、耗时、客户端 IP、上游地址
- 网关层（如 Kong、Spring Cloud Gateway）：看路由是否匹配、有无鉴权失败、限流拦截
- 业务服务日志：查具体处理逻辑，比如参数解析异常、DB 查询超时、第三方接口返回错误
- 中间件日志（Redis、MySQL 慢日志、消息队列）：结合时间戳和 request_id 关联上下文（部分中间件需自定义埋点）
借助日志平台做关联分析
手动 grep 效率低，推荐用 ELK、Loki 或阿里云 SLS 这类平台，把 $request_id 设为关键字段（如 Loki 的 label 或 ES 的 keyword 字段）。
- 在 Kibana/Loki Explore 中输入 {job="nginx"} |~ `abc123...`，再叠加其他 job 标签快速切换查看
- 用 Trace ID 对齐时注意：若系统同时用了 OpenTelemetry 的 trace_id，建议让 $request_id 和 trace_id 相同或建立映射，避免两套 ID 增加理解成本
- 可配置告警规则：当某 request_id 在多个服务中连续出现 ERROR 级别日志，自动聚合推送
补全缺失环节：日志里没打出来怎么办
常见于老服务未接入、异步任务、定时脚本或 DB 层。这时需要“以时间为锚点”辅助定位。
- 记下 $request_id 对应的精确时间（如 2024-06-15T14:23:08.123+08:00），在缺失日志的服务中按秒级范围搜索前后 3–5 秒日志
- 检查异步任务是否丢失传递：比如用户下单后发 MQ，消费者服务日志没打 request_id，就需在生产者侧补上，并作为 message header 透传
- 数据库操作可通过 SQL 中的注释携带，例如：/* request_id=abc123 */ UPDATE order SET status=2 WHERE id=123;，再配合 MySQL general_log 或慢日志解析
