链路追踪详解：从一条慢请求到根因定位

为什么日志和指标定位不了慢请求

线上一个下单接口的 P99 突然从 300ms 涨到 2s，日志里每条调用都"正常返回"，指标只告诉你"变慢了"，不告诉你慢在哪一跳。一个请求要经过网关、订单、库存、支付四个服务，再落到数据库和缓存，任何一跳都可能拖慢整体。链路追踪的思路很简单：给每个请求分配一个全局唯一的 trace_id，把跨服务的调用串成一条完整调用链，哪一跳耗时最长、哪一跳报错，展开就看清。

三个核心概念：Trace、Span、上下文传播

• Trace：一次完整请求的整条调用链，用 trace_id 唯一标识；
• Span：链上的一个单元，代表一次具体操作（一次 HTTP 调用、一条 SQL），记录起止时间、耗时和标签；
• 上下文传播：把 trace_id、span_id 通过请求头传给下游，让散在不同服务里的 Span 能拼回同一条 Trace。

OBSERVE 后端遵循 OpenTelemetry 标准，任何按 OTel 规范上报的数据都能直接接入，不绑定特定 SDK。你在应用里埋点，采到数据交给 OBSERVE，中间不用做格式转换。以后换后端，埋点代码一行不动。

慢请求定位四步法

一条 Trace 在 OBSERVE 里展开是一棵调用树，定位慢请求有固定路径：

1. 用 trace_id 或 service + 时间范围检索出目标 Trace；
2. 看调用树里每个 Span 的耗时分布，圈出最长的那个；
3. 点开 Span，看它调了哪些下游、带了什么标签和事件；
4. 关联这个 Span 时间窗内的日志和指标，确认是 DB 慢、网络抖动还是代码问题。

第三步和第四步是关键。Span 里带着 SQL 语句和耗时，旁边就是这条语句对应的慢查询日志，不用在日志和追踪两个系统之间来回切。慢 SQL 是"慢在哪"最常见的答案，而这套关联让你从"接口慢"到"这条 SQL 慢"只花两步。

服务拓扑与依赖分析

把所有 Trace 聚合起来，就能自动画出服务调用拓扑：谁调谁、调用量、错误率、平均耗时。这对理解系统全貌、接手没文档的老系统尤其有用。拓扑上一个节点变红，说明它错误率或延迟异常，点进去就是对应的 Trace 样本。

拓扑还能暴露隐藏依赖：一个早该下线的旧服务还在一直接收调用，图上清清楚楚。这类发现靠人工翻代码很难找，靠拓扑一眼看出。

采样策略：成本与覆盖的平衡

全量追踪成本高，固定比例采样又怕漏掉异常。OBSERVE 推荐尾采样：正常请求按比例采（如 10%），慢请求和出错请求 100% 保留，成本可控的同时保证"值得看的"请求都有完整链路。采样策略可按服务单独配置，核心链路调高、边缘链路调低。

落地建议

• 从核心链路开始接入，先给下单、支付埋点，再逐步铺开；
• 统一 Span 命名规范，各团队各写各的，拓扑和检索都会乱；
• 把 trace_id 打进应用日志，日志和 Trace 才真正串起来，故障时凭一条日志里的 trace_id 就能反查整条链路。