适用场景

链路追踪解决的是「一次请求慢在哪一段」。落地难点不在装组件，而在采样与关联：全量采样成本高、采样率低了抓不到故障、trace_id 不进日志等于白装。

配置步骤（采样策略与成本平衡）

# 采样策略建议（三级）
1) 基线采样：1%-10%（按流量定），覆盖正常请求
2) 错误强制采样：HTTP 5xx / 业务异常 / 超时 100% 采样
3) 慢请求强制采样：耗时超过阈值（如 P99 或 1s）100% 采样

# 实现方式
- 首部采样（Head-based）：入口决定是否采样，成本低但可能漏掉错误
- 尾部采样（Tail-based）：Collector 汇总后决定，能保住错误与慢请求，成本略高
- 推荐：入口按比例 + Collector 尾部采样兜底错误/慢请求

# 容量估算
日均请求 1000 万 × 5% = 50 万 trace/天
每 trace 平均 10 span × 1KB ≈ 10KB -> 5GB/天，保留 7 天 ≈ 35GB（不含副本）

关键参数与建议

  • 接入方式：优先无侵入（Agent/Sidecar），改代码成本高且容易漏埋点
  • trace_id 贯穿：网关生成或透传，应用日志必须打 trace_id，否则排障时无法串联
  • 采样策略：平时 1%-10% 尾采样，故障期或错误请求 100% 采样
  • 上下文传播：HTTP header（traceparent）、消息队列、定时任务都要透传
  • 数据保留：明细保留 7-15 天，聚合指标长期保留
  • 性能开销：Agent 采样与上报要限速，避免把业务拖慢
  • 验收：能对一次真实慢请求还原出完整调用链，含每段耗时与依赖

容易踩的坑

  • 只做首部采样，错误请求被采样率直接丢掉
  • 尾部采样窗口设太长，Collector 内存被撑爆
  • 采样率写死不做动态调整，故障期抓不到数据
  • 高流量接口与低流量接口用同一个采样率
  • 没算过存储容量，上线一周存储就满
  • 采样开关没有审计，改错了没人知道

验证与巡检

# 采样有效性检查
1) 故障复盘时是否有 trace 可看（应有）
2) 存储量是否符合估算（偏差 < 30%）
3) Collector 内存与队列水位 < 70%
  • 巡检：错误/慢请求 trace 100% 可查、存储量符合估算、采样配置有变更记录

小结

链路追踪验收：随机挑一条用户投诉的慢请求，能在 3 分钟内指认慢在哪一段（应用、数据库、缓存、第三方），而不是「感觉都慢」。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。