适用场景

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

配置步骤（trace 与日志、指标关联）

# 三支柱关联的落点
1) trace_id：贯穿网关 -> 应用 -> 数据库 -> 消息队列
2) 日志：每条日志带 trace_id + service + host
3) 指标：指标带 service、instance 标签，与日志的 host 对齐

# 排障动线（实测应做到）
- 从告警（指标）-> 找到异常实例
- 从实例 -> 找到该时段的错误日志
- 从错误日志里的 trace_id -> 打开完整链路，看每段耗时
- 从链路中的慢 span -> 定位到具体 SQL 或第三方调用

# 落地检查项
- 日志采集器是否解析出 trace_id 字段（而不是塞在 message 里）
- trace 系统是否支持按 trace_id 直查
- 时间是否统一（NTP），否则三边数据对不齐

关键参数与建议

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

容易踩的坑

  • trace_id 只写在 message 文本里，检索不到
  • 时间不同步，日志与 trace 差几秒，定位到错误时段
  • 指标缺少 instance 标签，告警后不知道是哪台
  • 日志里的 host 是容器名，与指标里的实例标识对不上
  • 只采购了 trace 系统，没人接日志与指标，三支柱各自为政
  • 排障流程没写下来，值班人员不知道怎么串

验证与巡检

# 关联可用性验收（每月一次演练）
1) 随机取一条 5xx 日志，能否在 3 分钟内拉到完整 trace
2) 从告警实例能否直接跳到该实例日志
3) 记录演练耗时，目标 < 3 分钟
  • 巡检：trace_id 字段可检索、三边时间一致、月度关联演练有记录

小结

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

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