用户投诉的那次请求，能否一次查询看到「重试→降级→兜底→最终返回」？
一次失败的全貌，要看三段日志
故障排查最难的是把链路串起来 ✗：重试了几次 ✔、降级到哪一级 ✔、
最终返回给用户的是什么 ✔ —— 如果这三件事分别在三个系统里 ✔，就很难还原 ✔。
把"重试 + 降级 + 最终结果"用同一个 trace 串起来 ✔。
一、要串起来的六个事件
```
① 请求进入（trace_id 生成）
② 第一次调用失败（错误码 + 是否可重试）
③ 重试（第几次、等待多久、结果）
④ 降级触发（进入哪一级、为什么）
⑤ 兜底结果（是否命中缓存、是否规则兜底）
⑥ 最终返回（用户实际看到什么 + 是否标注了降级）
```
第 ⑥ 项最关键 ✗→✔：只有它记录了"用户到底看到了什么" ✔ ——
很多系统只记到 ④ ✔，事后无法回答"用户看到的是不是兜底结果" ✔。
二、三条实现要求
1. trace 贯穿全链路 ✔（包括重试与降级分支 ✔ —— 见日志那篇 ✔）；
2. 每段都记状态与原因 ✔（不要只记"失败" ✔ —— 记错误码与分类 ✔）；
3. 降级与兜底必须留痕 ✔（哪个开关生效、哪条规则命中 ✔）。
三、四条"一次查询能回答"的问题
```
① 这次请求重试了几次？每次为什么失败？
② 有没有降级？降到哪一级？用户被通知了吗？
③ 最终结果来自模型、缓存还是规则兜底？
④ 这次请求一共花了多少（含重试成本）？
```
第 ④ 项常被漏 ✗：重试成本要算进这次请求 ✔（否则成本归因不到具体请求 ✔）。
四、三个反模式
· 重试日志与主日志分开 ✗（无法关联 ✔）；
· 降级只记"已降级" ✗（不记哪一级、为什么 ✔）；
· 兜底结果不标注 ✗（用户与复盘者都不知道 ✔ —— 见沉默失败那篇 ✔）。
五、一条判据
> 给一个"用户投诉答得不对"的请求 ✔，你能否在一次查询里看到"重试→降级→兜底→最终返回"的全貌 ✔？
> 不能，说明失败链路还没串起来 ✗。
本文由云枢 AI导航整理，内容以官方来源为准。
相关文章
顺序阅读
第 171 / 171 篇