用请求 ID 串联日志是什么
分布式系统中，一次外部请求会穿过网关、应用集群、缓存、数据库与下游服务。在入口生成一个请求标识（trace id 或 request id）并逐跳透传、写进每条日志，就能把这个请求在各组件里的记录串成一条完整的链。它是应用层溯源的主线，能把「谁点了什么」还原成可读的调用路径。
基本信息
| 用途 | 跨服务请求级溯源 |
|---|---|
| 载体 | trace_id / request_id / X-Request-Id 头 |
| 传播方式 | 入口生成、下游透传、写入每条日志 |
| 前提 | 各组件都记录该字段，链路才完整 |
典型使用场景
- 排查一次异常操作对应的完整调用路径
- 定位慢请求卡在哪个组件
- 判断攻击请求是否真的到达业务逻辑，而不是停在前端
- 把分散在各服务的日志整理成一条可读的请求链写进报告
- 复盘时评估哪一段链路缺少可观测性
- 检查定时作业与异步任务是否缺失请求标识，补齐链路空白
全栈检索
全栈检索
grep -r 'trace_id=7f3a' /var/log/app/ # 应用目录按 trace id 检索
zgrep -h '7f3a' /var/log/nginx/access.log* # 网关侧入口记录
grep '7f3a' /var/log/app/*.log | awk '{print $1,$2,$3,$NF}' # 各服务记录按时间排列
# 网关侧回写 X-Request-Id 给客户端，便于事后对照与用户报障定位常见字段名
| 字段 | 出现位置 | 注意 |
|---|---|---|
| trace_id | 支持链路追踪的服务 | 一次请求唯一，可跨异步任务传递 |
| request_id | 应用与网关日志 | 同一请求内唯一，异步场景可能丢失 |
| X-Request-Id | HTTP 头部 | 客户端可预先传入伪造值，入口应重新生成 |
| span_id | 链路追踪的跨度标识 | 用于判断调用的父子嵌套关系 |
部分组件不传递头部（旧版本中间件、异步任务、定时作业），链会在中间断掉；这时按日志时间与请求路径就近补接，并注明该段为推断。
由客户端传入的标识不可全信：入口网关若直接沿用外部传入的请求 ID 而不重新生成，攻击者可以复用固定值污染日志关联。