链路追踪Distributed Trace

先看见下单卡住，再把这一次请求拆成跨度

左边是变慢的下单页，右边是同一 traceId 的瀑布。展开后最长段在 DB；把 cache 标成原因时，短条会被错标。

知识点：慢在最长的子跨度

上面的工作台已经演示了核心关系，这里只给可复用的命名。

• 根跨度只说明整次慢，不说明慢在谁。
• 展开后找最长子跨度；出错短跨度要另案处理，不能当成瓶颈。
• 日志和错误追踪应携带同一 traceId，才能来回跳。

什么时候用、怎么用

跨服务请求变慢、偶发超时，或你需要证明慢在数据库还是下游时用链路追踪。

• 入口：打开链路追踪后台，用这次请求的 traceId 打开瀑布。
• 最短路径：固定同一订单 → 打开 trace → 展开子跨度 → 标最长段 → 再查该服务日志。
• 单页卡顿优先看性能分析；跨服务等待才优先看 trace。

正反例：同一 401ms 下单，只改你标哪一段

目标都是让下单恢复。差别在于有没有打中真正耗时的跨度。