让一次请求被追踪到
网关生成或透传一个唯一的请求标识，写进转发头与响应头：排障时用它在网关、引擎与业务日志之间串起时间线，用户报障时也能直接按它检索。关键约定是标识只在入口生成一次，各层只透传不改写，并把响应头回带给调用方。
基本信息
| 适用平台 | Nginx 网关与应用网关 |
|---|---|
| 生成方式 | 网关生成，或透传调用方带来的标识 |
| 写入位置 | 转发请求头与响应头 |
| 与日志关系 | 访问日志与业务日志都记录该标识 |
Nginx 片段
Nginx 片段
location /v1/ {
proxy_set_header X-Request-ID $request_id;
add_header X-Request-ID $request_id always;
proxy_pass http://llm;
}典型使用场景
- 用户报障：让调用方提供标识，直接定位到请求
- 跨系统排查：三段日志按同一个标识串联
- 慢请求分析：按标识拼接各层耗时
- 配额溯源：按标识反查调用方与用量消耗
- 链路对齐：网关、引擎与应用三方日志取交集，快速定位是哪一段慢
各层记录位置
| 记录位置 | 来源 | 排查用途 |
|---|---|---|
| 网关访问日志 | 网关生成时写入 | 确认请求是否到达入口 |
| 引擎日志 | 从请求头透传 | 确认生成开始与结束时间 |
| 客户端日志 | 从响应头读取 | 确认调用方的等待时长 |
客户端把响应头里的标识记进自身日志：跨系统排查时无需再对时间戳。
透传外部标识时要校验长度与字符集：异常值直接写进日志会带来解析与注入方面的麻烦。
标识与日志格式要同时配置：格式串里没有它，光设置请求头是查不到的。
确认标识能被检索系统解析成独立字段：只当普通文本存着，检索时仍然要全量扫描。
网关重启不影响标识可用性：它是随请求生成的短随机串，不需要额外持久化。
标识长度留有余量：网关生成的随机串已经够用，不必为可读性把时间戳与主机名都堆进去。