把重试与降级的日志串起来：一次失败的全貌

故障排查难在把链路串起来。本文给出要串起来的六个事件（重点是最终返回）、三条实现要求、四条一次查询能回答的问题与三个反模式。

一次失败的全貌，要看三段日志

故障排查最难的是**把链路串起来** ✗：重试了几次 ✔、降级到哪一级 ✔、

最终返回给用户的是什么 ✔ —— 如果这三件事分别在三个系统里 ✔，就很难还原 ✔。

**把"重试 + 降级 + 最终结果"用同一个 trace 串起来** ✔。

```

① 请求进入（trace_id 生成）

② 第一次调用失败（错误码 + 是否可重试）

③ 重试（第几次、等待多久、结果）

④ 降级触发（进入哪一级、为什么）

⑤ 兜底结果（是否命中缓存、是否规则兜底）

⑥ 最终返回（用户实际看到什么 + 是否标注了降级）

```

**第 ⑥ 项最关键** ✗→✔：只有它记录了"用户到底看到了什么" ✔ ——

很多系统只记到 ④ ✔，事后无法回答"用户看到的是不是兜底结果" ✔。

1. **trace 贯穿全链路** ✔（包括重试与降级分支 ✔ —— 见日志那篇 ✔）；

2. **每段都记状态与原因** ✔（不要只记"失败" ✔ —— 记错误码与分类 ✔）；

3. **降级与兜底必须留痕** ✔（哪个开关生效、哪条规则命中 ✔）。

```

① 这次请求重试了几次？每次为什么失败？

② 有没有降级？降到哪一级？用户被通知了吗？

③ 最终结果来自模型、缓存还是规则兜底？

④ 这次请求一共花了多少（含重试成本）？

```

**第 ④ 项常被漏** ✗：重试成本要算进这次请求 ✔（否则成本归因不到具体请求 ✔）。

**重试日志与主日志分开** ✗（无法关联 ✔）；

**降级只记"已降级"** ✗（不记哪一级、为什么 ✔）；

**兜底结果不标注** ✗（用户与复盘者都不知道 ✔ —— 见沉默失败那篇 ✔）。

> 给一个"用户投诉答得不对"的请求 ✔，你能否在**一次查询**里看到"重试→降级→兜底→最终返回"的全貌 ✔？

> 不能，说明失败链路还没串起来 ✗。