2. 分布式追踪基础：Trace/Span 概念、OpenTelemetry 标准、Jaeger/Zipkin 选型对比
2.1 核心概念：Trace 与 Span
分布式追踪的核心目标是还原一次请求在多个微服务之间的完整调用链路。其数据模型由两个基本元素构成：Trace（追踪）和 Span（跨度）。
- Trace：代表一次完整的请求或事务在分布式系统中的端到端路径。一个 Trace 由多个 Span 组成，共享同一个全局唯一的
TraceID。 - Span：代表 Trace 中的一个命名、计时的工作单元。每个 Span 记录了一个服务或组件处理请求的起始时间、结束时间、状态以及元数据（如 HTTP 方法、URL、错误信息）。
关键关系：Span 之间通过
ParentSpanID 形成树状层级结构。根 Span（Root Span）没有父 Span，代表整个 Trace 的入口点。
下表总结了 Trace 与 Span 的核心属性：
| 属性 | Trace | Span |
|---|---|---|
| 标识 | TraceID（全局唯一） | SpanID（Trace 内唯一） |
| 粒度 | 一次完整请求 | 一个服务/组件内的操作 |
| 结构 | Span 的有向无环图（DAG） | 树状节点，包含 ParentSpanID |
| 生命周期 | 请求开始到结束 | 操作开始到结束 |
| 典型数据 | TraceID, Span 列表, 服务拓扑 | SpanID, 开始/结束时间, 标签, 日志 |
以下 SVG 图展示了一个典型 Trace 的 Span 层级结构：
2.2 OpenTelemetry 标准：统一的可观测性数据规范
OpenTelemetry（简称 OTel）是 CNCF 孵化的可观测性标准，旨在统一分布式追踪、指标和日志的数据采集与传输格式。它解决了过去 Jaeger、Zipkin、Prometheus 等工具各自为政、数据格式不互通的问题。
OpenTelemetry 的核心组件包括：
- API：定义 Trace、Span、Metric、Log 的数据模型和操作接口，与语言无关。
- SDK：实现 API，提供采样、上下文传播、导出等能力。
- Collector：独立的代理服务，接收、处理、导出遥测数据，支持多种后端（Jaeger、Zipkin、Prometheus 等）。
- Exporter：将数据发送到指定后端存储或分析系统。
标准优势：OTel 提供了统一的
W3C Trace Context 传播标准（traceparent 头），使得不同语言、不同框架的服务可以无缝串联 Trace，无需关心底层实现。
以下 SVG 图展示了 OpenTelemetry 的架构与数据流：
2.3 Jaeger vs Zipkin：选型对比
Jaeger 和 Zipkin 是目前最流行的两种分布式追踪后端系统，均支持 OpenTelemetry 数据接入。下表从多个维度进行对比，帮助你在值班台高可用方案中做出选择。
| 对比维度 | Jaeger | Zipkin |
|---|---|---|
| 开发方 | Uber → CNCF（毕业项目） | Twitter → CNCF（孵化项目） |
| 存储后端 | Elasticsearch、Cassandra、Kafka、Badger（内存） | Elasticsearch、Cassandra、MySQL、内存 |
| UI 功能 | 丰富：服务拓扑图、Trace 对比、性能分析、依赖图 | 基础：Trace 查询、Span 详情、依赖图 |
| 高可用部署 | 组件多（Collector/Query/Agent/Ingester），架构复杂 | 组件少（Collector/Storage/UI），部署简单 |
| 采样策略 | 支持头采样、尾采样、自适应采样 | 仅支持头采样（通过 Brave 或 OTel） |
| 社区活跃度 | 高，更新频繁，文档完善 | 中等，维护稳定，新功能较少 |
| OTel 集成 | 原生支持 OTLP 协议 | 通过 OTel Collector 转换后接入 |
| 适用场景 | 大规模、复杂拓扑、需要深度分析 | 中小规模、快速部署、轻量级需求 |
选型建议：对于值班台高可用部署方案，如果团队运维能力较强且需要丰富的链路分析能力（如服务拓扑、Trace 对比），推荐 Jaeger；如果追求快速部署、组件简洁、资源占用低，推荐 Zipkin。两者均可通过 OpenTelemetry Collector 统一接入，降低迁移成本。