直接看TraceID对应Span序列并按时间排序可定位耗时异常环节；需先从入口日志提取TraceID（如traceparent头或x-trace-id字段），再依start_time排序、parent_id构建调用树，结合Annotation和P95/P99分位分析具体卡点。
直接看 TraceID 对应的完整 Span 序列，按时间顺序串起来，就能定位哪一环耗时异常。
找对 TraceID 是第一步
用户一次请求对应一个全局唯一的 TraceID，所有相关日志、Span 都带这个 ID。排查时必须先从入口日志（比如 API 网关或 FastAPI 的 access log）里提取它。常见位置：
- HTTP 请求头中：traceparent（W3C 标准格式，含 TraceID 和 ParentID）
- 自定义日志字段：trace_id 或 x-trace-id
- 若用 OpenTelemetry 自动埋点，TraceID 通常已注入 Structured Log 的上下文字段中
按 Span 时间戳排顺序，画出调用树
每个 Span 记录了开始时间（start_time）、结束时间（end_time），以及 parent_id 和 span_id。把同一 TraceID 下的所有 Span 拉出来，按 start_time 排序，再根据 parent_id 构建父子关系，就能还原真实调用路径。关键看：
- 单个 Span 耗时 = end_time − start_time：超过阈值（如 200ms）就标红
- 子 Span 总耗时远小于父 Span：说明父 Span 内有非调用开销（比如序列化、锁等待、DB 连接池阻塞）
- 多个同级 Span 并发但结束时间差异大：可能某实例负载高或网络抖动
结合 Annotation 定位具体阶段卡点
标准 Annotation（如 sr/ss/cr/cs）能进一步细化耗时归属。例如：
- sr 到 ss 的差值 = 服务端纯处理时间
- cs 到 sr 的差值 = 网络+网关转发延迟
- ss 到 cr 的差值 = 响应返回链路延迟
- 若 cs→sr 很长，但 sr→ss 正常 → 可能是上游压测流量打满网关，或 DNS 解析慢
别只盯平均值，要查 P95/P99 分位耗时
平均耗时掩盖毛刺。比如 100 次请求中 99 次 50ms，1 次 2s，平均才 70ms，但用户明显感知超时。建议：
- 在日志分析平台（如 Loki + Grafana、ELK + APM 插件）中按 TraceID 聚合后计算分位数
- 筛选出 P99 > 1s 的 Trace，再逐个展开其 Span 树
- 重点关注“耗时占比高 + 出现频次高”的 Span 类型（如某个 Redis 查询、某次下游 HTTP 调用）
不复杂但容易忽略：日志时间戳必须统一为 UTC 且精度到毫秒或微秒，否则 Span 顺序错乱，链路就串歪了。
