拆解 OBSERVE 链路追踪：Trace 与 Span 数据结构、服务拓扑自动生成、慢调用与错误率分析，以及 Trace 与日志、指标的一键关联，附带采样与成本控制建议。
链路追踪的核心是 Trace 和 Span。一次前端请求进入网关，经过订单服务、库存服务、数据库，产生一条 Trace；其中每个服务调用是一个 Span，用 span_id 串联出父子关系，用 trace_id 把整条链路串起来。OBSERVE 采集端接收 OTLP 协议的 Span 数据，存储时同时保留 trace_id、span_id、parent_span_id、service.name、耗时、状态码和自定义 attribute，后面所有分析都建立在这些字段上。
关键设计：Span 的 attribute 支持任意自定义键值，比如 order_id、user_id、region。埋点的时候把这些业务 ID 写进 Span，排查时就能按「订单号」直接反查整条链路，而不是在海量 Span 里大海捞针。
另一个常被忽略的点是 Span 类型。同一对服务之间的一次调用会同时产生一个 client Span 和一个 server Span，拓扑图上的边就是靠这两侧对齐的；消息队列还有 producer/consumer 两类。埋点时用 span.set_status(ERROR) 把异常显式标出来，错误率分析才算得准，而不是靠猜 HTTP 状态码。
微服务一多，谁调谁、调用量多少、慢在哪，光靠人肉梳理不现实。OBSERVE 根据 Span 的父子关系和 service.name 自动生成服务拓扑图：节点是服务，边是调用关系，边的粗细代表 QPS，颜色代表错误率或耗时。这张图是实时的，服务上下线、调用路径变化都会自动更新。
拓扑图的价值在故障时体现得最明显：某个下游变慢，上游跟着堆积，一眼能看出瓶颈在哪个节点，再点进去下钻到具体 Span。平时也能用它发现「死代码」——那些已经没人调用、却还在发请求的旧服务。上线新版本时，还能对比发版前后的拓扑差异，确认有没有服务意外下线或调用路径漂移。
光有拓扑不够，还要能定位到「为什么慢」。OBSERVE 的慢调用分析从三个维度下钻：
举例：订单接口 P99 突增，先按 Span 类型拆，发现 80% 的时间耗在 inventory-service 这个下游调用上；再点进这个 Span，看到耗时分解里「等待响应」占了大头；最后看同 trace_id 的日志，确认是库存服务在等数据库锁。三步定位到根因。
错误分析类似：错误率突增时，按 service.name、http.status_code、异常类型聚合，先定位是哪个服务、哪类错误，再下钻到单条错误 Trace 看完整上下文。
排查线上问题最常见的路径是：看监控发现某服务 P99 突增 → 点进链路看是哪个接口慢 → 需要日志确认具体报错。这三步如果割裂在三个系统里，来回切换很耗时间。OBSERVE 的做法是：日志和 Span 都带上 trace_id，在 Trace 详情页直接展示该链路触发的所有日志；指标异常也能一键跳到关联的 Trace 样本。反过来，从一条报错日志也能反查它属于哪条 Trace、上游是谁。
落地时建议把 trace_id 注入日志（主流日志框架都支持 MDC/Context），这是关联能成立的前提。这条不做，Trace 和日志就是两张皮。
接到告警说「订单接口超时」，查链路的路径是：先在检索框按 service.name=order-service 和耗时阈值筛出慢 Trace 样本，看它们的公共下游是谁；锁定可疑 Span 后，展开它的耗时分解，看是等数据库、等下游还是自身计算；再点进同 trace_id 的日志，看这几次调用前后有没有报错堆栈。熟练之后，从告警到定位根因能控制在几分钟内。平时把高频排查路径存成「快捷视图」，值班人不用每次重新组织查询。
全量采 Trace 存储成本会失控，尤其高 QPS 的服务。建议：生产默认用尾采样（Tail Sampling），把「带错误」「耗时超过阈值」的 Trace 100% 保留，正常请求按 1%-10% 采样；排查期可以临时提高采样率。OBSERVE 支持按 service.name、耗时、错误状态配置采样策略，冷数据自动归档到对象存储，把成本压下来。采样和埋点要一起规划：埋点写得好，采样才能精准地留高价值 Trace，否则要么成本高，要么关键链路被采没了。