3. 慢Trace判定标准
慢Trace的判定不能依赖单一维度。在生产环境中，单纯以固定耗时阈值判定容易漏报或误报，必须结合持续时间阈值、百分位数、错误率以及业务自定义规则四个维度进行综合判定。本章逐一拆解每种标准的适用场景与配置方法。
3.1 基于持续时间的阈值设定
这是最直观的判定方式：为Trace设置一个耗时上限，超过即判定为慢Trace。适用于接口响应时间稳定、SLA明确的场景。
| 阈值类型 | 说明 | 典型值 | 适用场景 |
|---|---|---|---|
| 固定阈值 | 所有Trace统一使用同一个耗时上限 | 500ms / 1s / 3s | 内部RPC、定时任务 |
| 分层阈值 | 按服务/接口/客户端类型分别设定 | 支付接口200ms，查询接口800ms | 多业务线混合部署 |
| 动态基线 | 基于历史数据自动计算阈值 | 均值+3σ / P99历史值 | 流量波动大的互联网应用 |
实践建议：固定阈值适合初期快速发现明显慢Trace；业务成熟后应逐步切换到动态基线，避免因业务增长导致大量误报。
3.2 基于百分位数的判定
百分位数判定关注的是尾部延迟，而非平均耗时。P99（99分位）是业界最常用的慢Trace判定基准，能有效过滤偶发尖刺。
核心公式：若 Trace 耗时 > P99_threshold，则判定为慢Trace。P99_threshold 通常取过去5分钟或1小时窗口内的历史数据计算。
| 百分位 | 含义 | 判定敏感度 | 推荐场景 |
|---|---|---|---|
| P95 | 5%的Trace超过此值 | 中等 | 非核心业务、批量任务 |
| P99 | 1%的Trace超过此值 | 较高 | 核心API、用户交互链路 |
| P999 | 0.1%的Trace超过此值 | 极高 | 金融交易、实时控制 |
注意：百分位数判定依赖足够的数据量。当窗口内Trace样本数少于1000时，P99/P999的统计意义会显著下降，建议同时设置最小样本数阈值。
3.3 基于错误率的判定
错误率判定关注的是质量维度。即使Trace耗时正常，但如果包含异常或错误，也应纳入慢Trace复盘范围。
- HTTP 5xx错误：服务端内部错误，直接判定为慢Trace。
- 业务异常码：如订单超时、库存不足等业务逻辑错误，按业务等级加权。
- 超时/熔断：RPC调用超时、熔断降级产生的错误，必须标记。
- 错误率阈值：当Trace内Span的错误率超过设定比例（如20%），即使总耗时正常也判定为慢Trace。
3.4 业务自定义规则
业务自定义规则是前三种标准的补充，用于处理特定业务语义的慢Trace场景。Tempo支持通过规则引擎配置灵活的判定逻辑。
| 规则类型 | 配置示例 | 判定效果 |
|---|---|---|
| 标签匹配 | span.tags[“db.type”] == “redis” && duration > 100ms | 仅对Redis调用判定慢Trace |
| 链路层级 | depth > 10 && duration > 2s | 深层嵌套链路单独判定 |
| 用户分组 | user.tier == “VIP” && duration > 200ms | VIP用户更严格的慢Trace标准 |
| 时段规则 | time between “10:00” and “11:00” && duration > 500ms | 高峰期特殊阈值 |
最佳实践：业务自定义规则应作为补充层，叠加在持续时间阈值和百分位数之上。建议先使用通用规则覆盖80%场景，再通过自定义规则处理剩余20%的特殊业务。
3.5 综合判定优先级
当多个判定标准同时生效时，Tempo采用“或”逻辑：只要满足任意一条标准，即判定为慢Trace。优先级从高到低为：
- 错误率判定（最高优先级，一旦发现错误直接标记）
- 业务自定义规则（按规则权重排序）
- 持续时间阈值（固定阈值 > 动态基线）
- 百分位数判定（P999 > P99 > P95）
这种设计确保质量异常（错误）优先于性能异常（耗时），同时保留业务灵活调整的空间。