分布式追踪：OpenTelemetry Collector

可视化演示

展示微服务调用链路追踪、OTel Collector三段式管道及多数据类型集成的三模态交互动画。

追踪基础概念

假设你在杭州寄出一件快递到北京。揽收员扫码，系统生成一个运单号；到了杭州分拨中心，再扫一次；到了北京转运中心，又扫一次；最后派送员签收，再扫一次。每一次扫描只记录“这一站在处理什么、花了多久”。在物流术语里，这件快递从寄出到签收的全部扫描记录，就是一条“完整旅程”。

分布式系统也一样。用户点一下“下单”，请求先打到前端服务，前端调用网关，网关调用订单服务，订单服务再查库存。我们把一次完整请求经过的所有服务调用，叫做一条 Trace（追踪）；其中每一次独立的服务处理，叫做一个 Span（跨度）。Span 就像那条扫描记录，记着：在哪个服务、什么时候开始、什么时候结束、它由谁发起。

Span 是 Trace 的基本单位。每个 Span 有四个关键信息：服务名（name）、自己的 ID（spanId）、父 Span 的 ID（parentId）、起止时间（startTime/endTime）。根 Span 没有父亲，它下面挂着一串子 Span，子 Span 下面还可能再挂孙 Span——所有 Span 按 parentId 组织起来，就形成一棵“调用树”。这就是为什么 Trace 在数学上可以写成一组 Span 的集合。

你还可以把 Trace 想象成快递的完整轨迹页：运单号是这页的标题，每个扫描点（Span）是页面上的一行记录，每行都写着上一站是谁（parentId）。物流客服之所以能三秒回答“到哪了”，就是因为这页轨迹被完整保存着。分布式系统里，SRE 能快速定位慢请求，同样靠这份“轨迹页”。

上下文传播

快递能走完全国，靠的是面单上的运单号。包裹每到一个网点，工作人员扫面单确认“这是哪件快递”，然后把面单原封不动传给下一站。如果哪个环节把单号抄错了，这件快递就成了“无头件”，再也查不到轨迹。在分布式追踪里，这个“运单号跟着包裹走”的过程，叫作 上下文传播（Context Propagation）。

服务 A 调用服务 B 时，A 必须把 traceId 和当前的 spanId 装进请求头，B 收到后才能在自己新建的 Span 里填上正确的 traceId 和 parentId，把自己挂到同一棵树上。OpenTelemetry 推荐使用 W3C 标准——在 HTTP 请求里加一个 traceparent 头，这个头就是“电子运单”。

traceparent 长这样：00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01。它用短横线分成四段：版本号（00）、traceId（32 位十六进制，全局唯一）、spanId（16 位十六进制，当前环节）、flags（采样标志，01 表示希望被记录）。下游服务收到后，把自己生成的 spanId 替换进第三段，再传给更下游——运单号就这样一站一站传下去。

这就像快递面单在每站交接时被读一次、更新一次“当前站编号”，但运单号永远不变。只要每个环节都遵守这个格式，无论链路有多深，都能靠 32 位的 traceId 把分散在几十个服务里的 Span 重新串成一条完整轨迹。

Collector 架构

全国网点成千上万，如果每个网点都直接把扫描记录发给物流 App 的数据库，格式五花八门，总部机房也会被请求淹没。于是物流公司建了区域分拨中心：各网点先扫描上报给分拨中心，分拨中心统一整理后再发往总部大屏。这个区域分拨中心，就是 OpenTelemetry Collector。

Collector 是 OpenTelemetry 提供的独立服务，它自己不产生追踪数据，只负责接收、加工、转发。应用侧的 SDK 把 Span 用 OTLP 协议（OpenTelemetry 的默认传输协议，相当于标准化的货车线路）发给 Collector。Collector 经过一条“流水线”处理后，再导出给 Jaeger、Zipkin 或云厂商后端。业务团队从此只需要对接 Collector，不必关心后端是谁。

Collector 的流水线由三部分组成：Receiver（接收器）是管道入口，支持 OTLP、Zipkin 等多种协议；Processor（处理器）是中间加工环节，负责批处理、采样、过滤、脱敏；Exporter（导出器）是管道出口，把数据发给目标后端。数据只能从 Receiver 流向 Exporter，像包裹在分拨中心必须“先进场、再分拣、最后装车”一样，方向从不颠倒。

有了 Collector 这个“区域分拨中心”，即使未来换掉后端大屏（比如从 Zipkin 换成 Jaeger），业务代码一行都不用改，只需在 Collector 配置里换一个 exporter。这就是为什么它成为现代可观测性体系的标准件。

数据收集优化

双十一全网一天几亿件快递，如果总部对每件快递都做“全程视频追踪”，存储成本高到无法想象。物流公司的做法是：网点攒够一车再发走（批处理），同时只对部分快递做深度轨迹分析（采样）。Collector 的 Processor 里，恰好内置了这两板斧。

第一个是 batch 批处理器：把短时间内的多条 Span 打包成一个请求再发送，减少网络往返次数。默认配置下，可能攒够 512 条 Span 或等 5 秒触发一次发送。第二个是采样：用随机数决定保留哪条 Trace，常见的有固定比例采样（如保留 10%）和尾部采样（链路结束后按“是否出错”决定保留）。

采样可以写成一条简单的判断：生成一个 0 到 1 之间的随机数 r，当 r 低于保留率 rate 时保留，否则丢弃。错误链路可以配置 100% 保留，保证故障现场不丢。此外 Collector 还内置队列和背压机制：后端变慢时数据先排队，队列满了就丢弃超量的 Span 而不是无限堆积内存——就像分拨中心的传送带满了，宁可拒收也不让包裹堵满仓库。

批处理省流量、采样省存储、队列防雪崩，这三件事分别回答了运维最关心的三个问题：网络贵不贵、存储贵不贵、宕机会不会。数据收集不是“只要全量就好”，而是一门在成本与完整度之间找平衡的艺术。

Jaeger 集成

快递数据汇到总部后，管理员怎么看？现实中你会打开物流 App，输入运单号查轨迹。在追踪体系里，这个“物流 App”常常就是 Jaeger——一个开源的分布式追踪后端，提供存储、查询界面和依赖关系图。

Collector 通过 exporter 把处理好的 Span 发给 Jaeger：通常走 OTLP 协议，指到 Jaeger 的 4317 端口。Jaeger 把数据写入 Elasticsearch 或 Cassandra 存储，再通过 jaeger-query 服务提供网页查询。SRE 只需要在搜索框输入 traceId，就能看到这条请求途经的每一个服务。

Jaeger 的查询界面是排查故障的主战场。进入一条 Trace，会看到瀑布图：横向是时间，每个 Span 按“谁调用谁”的层级纵向排列。哪个 Span 的横条最长，瓶颈就在哪个服务。Jaeger 还能生成服务依赖图，展示服务间的调用关系与流量大小，帮助 SRE 一眼看清系统结构。

从“快递轨迹页”的角度看，Jaeger 就是最直观的那一页：运单号查轨迹，每个扫描点按时间画成横条，哪一站延误一眼可见。Collector 负责把数据送到这里，Jaeger 负责让它好看好用。

Zipkin 集成

不是所有物流公司都用同一套大屏。有些公司自建系统，用的是另一套成熟方案——Zipkin。Zipkin 是 Twitter 开源的分布式追踪系统，问世比 OpenTelemetry 早得多，很多老项目早已用它埋点。新体系想接老数据，就得靠“翻译”。

OpenTelemetry Collector 内置了 zipkin receiver 和 zipkin exporter：既能接收老系统用 Zipkin 格式上报的数据，也能把 OTLP 数据转成 Zipkin v2 的 JSON 格式再转发给 Zipkin。这意味着哪怕业务代码是五年前用 Zipkin 埋的点，也可以通过 Collector 平滑接入新体系，不必大改代码。

选型对比上：Jaeger 与 OpenTelemetry 同为 CNCF 项目，对 OTLP 原生支持最好，适合新项目；Zipkin 生态更老，在存量系统中占有率更高，但 JSON/HTTP 上报开销稍大。更常见的做法不是二选一，而是让 Collector 同时开多个 exporter——数据各发一份，新系统看 Jaeger，老监控看 Zipkin，过渡期平稳度过。

Collector 像一位熟练的“翻译官”：面单从中文学成英文，再从英文翻回中文，包裹本身（Trace ID）始终没变。有了它，新旧系统共存不是难题，而是配置里的两行代码。

统一可观测性

一个成熟的物流公司，光有快递轨迹还不够。调度室要看今天的总运量趋势（什么时候爆仓），仓库要看每件快递的操作备注（为什么滞留），客服要能查每件快递的完整轨迹（到底到哪了）。这三样各司其职，合起来才叫“全程可控”。在 IT 系统里，它们就是可观测性的三大支柱：Metrics、Logs、Traces。

Metrics 是聚合指标：QPS、延迟百分位、错误率，回答“发生了什么趋势”；Logs 是事件明细：一条条带时间戳的错误信息和上下文备注，回答“具体发生了什么”；Traces 是请求路径：一次请求经过哪些服务、每步多久，回答“为什么变慢”。三者通过 traceId 关联起来，构成完整拼图。

OpenTelemetry 的贡献，是把三类信号的采集、传输和导出协议统一了。Collector 可以同时接收 Metrics 与 Traces，日志里也可以携带 traceId 字段。SRE 的排障黄金流程是：先用 Metrics 发现“订单服务 P99 飙升”，再用 Traces 定位“是库存服务这个 Span 最慢”，最后用 Logs 查看“具体是慢 SQL 还是连接池耗尽”。三步缺一不可。

回到物流：Metrics 是日报表，Logs 是交接备注，Traces 是运单轨迹。只装一类的公司都做不到“全程可控”。对 SRE 而言，掌握三支柱协同，才能从一个告警出发，五分钟内回答“哪里坏了、为什么坏、影响多大”——这正是可观测性的终极意义。

AI 应用场景

Python 演示

"""Mini simulation of distributed tracing using a logistics metaphor."""import timeimport uuid  class Span:    """A span: one scan record at one station."""     def __init__(self, name, span_id, parent_id, trace_id):        self.name = name        self.span_id = span_id        self.parent_id = parent_id        self.trace_id = trace_id        self.start = time.time()        self.end = None     def finish(self):        self.end = time.time()     def duration_ms(self):        return (self.end - self.start) * 1000 if self.end else 0  class SimpleTracer:    """Mini tracer: stores all spans and propagates the trace id."""     def __init__(self):        self.spans = []     def start_span(self, name, parent=None):        trace_id = parent.trace_id if parent else uuid.uuid4().hex[:16]        parent_id = parent.span_id if parent else None        span = Span(name, uuid.uuid4().hex[:16], parent_id, trace_id)        self.spans.append(span)        return span  def wait(seconds):    time.sleep(seconds)  def build_trace(tracer):    """Build a call chain: front -> gateway -> order -> stock."""    root = tracer.start_span("前端请求")  # 根 Span: 生成运单号    wait(0.01)    gateway = tracer.start_span("网关服务", root)  # 把父 Span 传入以继承 traceId    wait(0.02)    order = tracer.start_span("订单服务", gateway)    wait(0.03)    stock = tracer.start_span("库存服务", order)    wait(0.015)    stock.finish()    order.finish()    gateway.finish()    root.finish()    return root  def print_trace(root, spans):    """Print all spans sorted by start time."""    print("Trace ID:", root.trace_id)    print(f"{'服务':<10}{'span_id':<18}{'parent_id':<18}{'耗时(ms)':<10}")    for s in sorted(spans, key=lambda x: x.start):        parent = s.parent_id if s.parent_id else "-"        print(f"{s.name:<10}{s.span_id:<18}{parent:<18}{s.duration_ms():<10.2f}")  def main():    tracer = SimpleTracer()    root = build_trace(tracer)    print_trace(root, tracer.spans)  if __name__ == "__main__":    main()

1. class Span:一条扫描记录，保存服务名、spanId、parentId、traceId 和起止时间。
2. self.parent_id = parent_id记录“上一站是谁”，这是还原调用树的关键字段。
3. trace_id = parent.trace_id if parent else uuid.uuid4().hex[:16]有父节点就继承同一个运单号，没有就新建一个，代表全新链路。
4. gateway = tracer.start_span("网关服务", root)创建子 Span 时把父 Span 传进去，这就是“上下文传播”在代码中的体现。
5. stock.finish()环节结束，记录结束时间，之后才能计算这个 Span 的耗时。
6. print_trace(root, tracer.spans)遍历所有 Span，按 parent_id 串联并打印，还原完整 Trace。

常见误区

面试题