Go OpenTelemetry 链路追踪：Context 传播、Span 设计与慢调用定位

微服务链路一长，单看日志和指标只能知道“慢了”，却不知道慢在哪个服务、哪个 Redis 或哪条 SQL。链路追踪的作用是把一次请求拆成可对齐的时间线。

解决方案思路

入口中间件创建根 Span，把 context 传给内部函数和下游调用；每个关键依赖创建子 Span，记录 route、db.system、cache.key_type、error 等属性。慢调用定位时先看 Trace 时间线，再回到日志和 pprof。

核心代码示例

ctx, span := tracer.Start(r.Context(), "Order.Query")
defer span.End()
span.SetAttributes(attribute.String("route", "/orders/:id"))
if err != nil {
    span.RecordError(err)
}

运行逻辑

网关、Go 服务、Redis、数据库和下游服务的 Span 会按时间线排列。哪一段耗时最长，哪一段出现 error event，就优先从那里进入日志、指标或 profile 证据。

重点观察指标

• trace 覆盖率、采样率和 exporter 错误数
• 慢 Span 的 service、route、dependency 分布
• trace_id 与日志 request_id 的关联成功率

常见误区

• context 没有传下去，导致 trace 断裂
• Span 名称包含动态 ID，无法聚合
• 把过多业务字段放进 attribute 造成高基数

参考方案

• OpenTelemetry Go 文档
• context 官方文档

落地检查

• 字段、指标和 Span 名称要稳定，便于长期聚合。
• 上线前先在灰度环境验证采集成本和数据量。
• 告警必须能指向 owner、排查入口和回滚方案。