分布式 Tracing：Trace 很长，不代表问题更清楚

分布式 TracingTrace 很长不代表问题更清楚分布式系统接入 tracing 后很容易生成巨长的 trace网关、鉴权、RPC、存储、缓存、模型调用全都串起来。可 trace 很长不代表问题更清楚。span 命名混乱、标签缺失、错误没标记最后只是一条彩色长蛇。好的 tracing 要帮助定位瓶颈和责任边界。它应该告诉你请求慢在哪一段、失败在哪一层、重试发生了几次而不是把所有函数调用都塞进去。一、先定义关键 Span不要给每个小函数都建 span。先覆盖服务边界、下游调用、队列等待、存储读写和模型推理这类关键节点。flowchart LR A[API Gateway] -- B[Auth] B -- C[Scheduler Queue] C -- D[Inference RPC] D -- E[Storage Write]Span 的粒度要能回答排查问题。太粗看不出瓶颈太细看不出结构。二、标签比数量更重要一个 span 至少要有 service、operation、status、tenant、retry、queue_wait、model 等关键标签。标签缺失聚合分析就做不了。tracing::info_span!( inference_rpc, model %model, tenant %tenant_id, retry retry_count, queue_wait_ms queue_wait );注意不要把用户输入、密钥或大文本写进 trace。可观测性不能变成数据泄露通道。三、错误要标在发生点下游超时就在下游 span 标 error队列过载就在 queue span 标 error。不要只在最外层返回 500。否则 trace 看起来只有入口失败根因埋在里面。错误类型要结构化比如 timeout、rate_limited、validation_failed、downstream_5xx。后续才能按类型统计。错误标记的一个进阶要求是区分绝对失败和重试成功。同一条 trace 里第一次调用超时返回了 error第二次调用重试成功如果 trace 里只保留最后一个 span 的状态分析时就会丢失重试历史。建议在 span 的 event 级别记录每次尝试用tracing::event!在重试发生时写入 attempt 序号、前一次失败的错误码和耗时而不是直接覆盖 span 的 status。这样在 Jaeger 或 Grafana Tempo 查看 trace 时间线时能看到清晰的红色→绿色切换快速判断是偶发抖动还是持续故障。另一个容易被忽略的细节是异步调用中的 span 时序问题如果下游是 fire-and-forget 模式span 应当明确标记async_modefire_and_forget避免在火焰图上被误解为耗时异常长的同步等待掩盖真正的 hot path。除了错误标记span 的耗时分析也需要主动设计。默认的 trace 可视化按耗时排序但最慢的 span 不一定是最该优化的——有些 span 本身就是异步等待如等队列、等 downstream优化它不如优化它等待的对象。因此在记录 span 时可以用 attribute 区分wait_time和exec_time这样聚合分析时能把等别人的时间和自己干活的时间分开。还有一个常见陷阱是 span 的 parent 关系在 Tokio 多线程环境下如果 task A 派发 task B但 B 跑在另一个 worker 线程span 的 parent 关系需要通过tracing::Instrument或手动传播Span来保持否则 trace 会断裂成多条不相关的子树排障时很难拼接完整请求链路。对于跨进程的 RPCpropagator 要同时传递 traceparent 和 tracestate后者在多租户场景下特别有用——可以在 tracestate 里写入 tenant_id 哈希让接收方在不解密 payload 的情况下做路由决策和采样优先级判断。四、采样策略要分层全量 trace 成本很高。可以正常请求低采样慢请求、错误请求、高价值租户提高采样。采样策略要可配置。trace_sampling: normal: 0.01 error: 1.0 slow_request: 1.0 vip_tenant: 0.2没有采样策略tracing 系统自己也会成为成本黑洞。Trace 还要和日志、指标打通。trace_id 应该进入结构化日志关键指标也要能按 trace exemplars 跳回样本。否则三套系统各看各的排障时还是要靠人肉拼接。log: trace_idabc123 spaninference_rpc errortimeout modelqwen metric: inference_latency_bucket{modelqwen} exemplarabc123可观测性不是工具堆叠是证据能互相跳转。还要控制 span 基数。tenant、model 可以作为标签用户输入、请求正文、动态错误全文不适合做标签。高基数字段会把存储和查询拖垮最后让 tracing 系统先出问题。上线验收可以很朴素一次慢请求必须能从指标跳到 trace再从 trace 跳到对应日志。跳不通就说明证据链还没闭合。五、总结分布式 tracing 的价值不在 trace 多长而在关键 span 清楚、标签有用、错误标在发生点、采样策略合理。Trace 是证据链不是流水账。证据越精准排障越快。