这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
采样策略与三类数据关联
为什么需要采样
不是所有请求都能完整追踪。高流量服务如果 100% 采集 trace，存储成本会很高。
采样策略
| 策略 | 说明 |
|---|---|
| 固定比例采样 | 例如 1% |
| 错误请求全量采样 | 排障价值最高 |
| 慢请求提高采样率 | 疑似问题优先 |
| 重要租户 / 核心链路定向采样 | 关键业务不丢 |
采样的坑
入口采样后，下游必须遵循同一个采样决策，否则 trace 会残缺：
网关采样决策：这条 trace 要采集
-> 订单服务：必须跟随，采集自己的 span
-> 支付服务：如果自行决定不采集
-> 结果：trace 只有前半段，残缺与日志和指标关联
链路追踪不能孤立存在：
- 日志里要带
trace_id。 - 指标标签里保留服务和接口维度。
- 告警里给出典型 trace 链接。
故障排障路径
告警payment P95 > 2s
指标看板延迟集中在 Payment Service
慢 traceMySQL query 120ms
相关日志trace_id 搜到 SQL 参数
根因慢 SQL / 锁等待 / 缺索引
关键认知：
链路追踪不能孤立存在。日志里要带
trace_id，
指标标签保留服务和接口维度，告警给出典型 trace 链接。
排障路径越短，平均恢复时间越低。
一句话
trace 采样要保护核心信号：**错误全量、慢请求提高采样率、入口决策下游跟随。**链路必须和日志（trace_id）、指标（服务维度）、告警（trace 链接）联动，排障路径才能闭合。
发现内容有问题？
告诉我们哪里需要改进。