结论：分布式追踪用全局唯一的 TraceID 标识一次完整请求，每个服务内的处理单元是 Span（带父子关系形成调用树），通过上下文传播（Context Propagation）在进程间传递 TraceID/SpanID，最终在收集端拼装成完整调用链。OpenTelemetry（OTel）是 CNCF 的可观测性标准，统一了 Traces/Metrics/Logs 的信号模型、SDK、采集协议（OTLP）和 Collector 组件。

展开：上下文传播是核心机制：入口服务生成 TraceID 和根 Span，调用下游时把 traceparent（W3C Trace Context 标准格式）塞进 HTTP Header 或消息元数据，下游解析后以它为父继续建 Span——跨线程、异步消息（Kafka 要往 header 里塞）断链是实践中最常见的问题。采样是成本与完整性的权衡：头部采样（请求入口按比率决定，简单但可能丢掉关键错误链路）、尾部采样（Collector 收齐整条链再决定保留，可保留全部错误链路，代价是缓冲开销大）。OTel 落地架构：应用通过 SDK 或自动埋点（Java agent、eBPF）产生 OTLP 数据 → Collector（接收-处理-导出管线，做采样、批处理、属性加工）→ 后端（Jaeger/Tempo/商业 APM）。价值主张是厂商中立：埋点一次，后端可换。易错点：1）Span 属性要控制基数，别把业务大对象塞进去；2）只埋网关和框架层不够，关键业务节点要手工加 Span 才有排障价值；3）Baggage 滥用会导致 Header 膨胀。