可观测性三支柱：Jaeger/Tempo分布式追踪

可视化演示

以Span/Trace数据模型展示一次请求的完整调用链，演示采样策略的成本控制，以及traceparent头跨服务传播的过程，可切换三种模式观察。

追踪基础概念

先回到快递的比喻。假设你在淘宝下单，快递公司给包裹贴了一张运单号。此后包裹每经过一个中转站，工作人员就扫码一次，录入“到达时间、离开时间、当前站点”。当运单号被查询时，你就看到一条完整的轨迹：杭州揽收 → 上海分拣 → 北京配送。这条轨迹，就是物流界的 Trace；而其中每一站的扫码记录，就是一个 Span。

在微服务架构中，前端请求到达网关后，会依次调用认证、订单、支付、库存等服务。分布式追踪系统为这条请求分配一个全局唯一的 Trace ID（运单号），每进入一个服务就创建一个 Span（扫码记录），记录服务名、操作名、开始时间、耗时，以及它的“上一站”是谁（父 Span ID）。将这些 Span 按照父子关系串起来，就得到一棵“追踪树”。

一棵追踪树可以用数学形式描述：它由一个 Span 集合和一组父子边构成。根节点对应入口请求，叶子节点对应最底层的数据库或缓存调用。

$$\displaystyle T = (S, E)$$

1. S 集合：表示一条 Trace 中所有工作单元记录的集合，每个元素是一个 Span。

$$\displaystyle S = \{\text{span}_0, \text{span}_1, \ldots, \text{span}_{n-1}\}$$

2. E 边集合：表示 Span 之间父子调用关系的集合，一条边说明“谁是调用方、谁是被调用方”。

$$\displaystyle E = \{(\text{span}_i, \text{span}_j) \mid \text{span}_i \text{ 是 } \text{span}_j \text{ 的父节点}\}$$

3. T 整体：由 S 和 E 共同构成一棵有向树，描述一次请求从入口到出口的完整路径。

$$\displaystyle T = (S, E)$$

所以，当用户说“下单接口好慢”时，你只要在追踪系统里输入 Trace ID，就能像查快递一样，看到请求在哪个服务停留最久、哪一段调用失败。这就是分布式追踪提供的第一个核心价值：全链路可见。

数据采集原理

快递员不会凭记忆在终点站复述包裹走过哪些站，而是每到一站就扫码录入。对应到代码世界，这个“扫码”动作就是埋点。当今的主流标准是 OpenTelemetry：它提供 SDK，可以在 HTTP 请求进来时自动创建 Span，也会在调用下游服务时自动把追踪信息“粘”在出站请求上。

请求从服务 A 调到服务 B，仅仅在 A 里创建 Span 是不够的，B 必须知道“自己属于哪条链路、A 的 Span 是谁”。这就是上下文传播（Context Propagation）。物流界的做法是随包裹携带一张“交接单”，上面写着运单号、上一站编号、时间戳；微服务界的做法是在 HTTP Header 或消息队列的 Metadata 中携带同样的信息。

$$\displaystyle C_i = (\text{traceID}, \text{spanID}, \text{parentSpanID})$$

1. traceID：整条链路的全局唯一标识，类似快递运单号，贯穿所有服务。

$$\displaystyle \text{traceID} \in \{0, 1\}^{128}$$

2. spanID：当前工作单元的唯一标识，相当于本站点扫码产生的流水号。

$$\displaystyle \text{spanID} \in \{0, 1\}^{64}$$

3. parentSpanID：指向父 Span 的指针，让服务 B 能把自己挂到树上正确的位置。

$$\displaystyle \text{parentSpanID} = \text{spanID}_{\text{parent}}$$

实际落地时，OpenTelemetry 的自动埋点已经覆盖了主流框架（Spring Boot、Gin、Express 等），它会在 RPC 调用的 Header 中写入 W3C 标准的 traceparent 字段。就像快递公司统一了“交接单”格式，各站点不用协商也知道怎么读。上下文传播是整棵追踪树能够“从根长到叶”的血管。

Jaeger架构

如果说分布式追踪是一套“快递运单系统”，那么 Jaeger 就是一套典型的“总部集中式”平台。它的架构可以拆成三个角色：快递员手里的扫码枪（Agent）、网点的分拣调度中心（Collector）、以及供客户查询运单轨迹的客服查询台（Query）。

Jaeger 最初由 Uber 开源，现为 CNCF 毕业项目。应用服务通过 SDK 把 Span 上报给本机 Agent（UDP 协议），Agent 做轻量校验后批量转发给 Collector；Collector 负责大规模接收、验证、索引并写入存储后端（支持 Cassandra、Elasticsearch、Badger 等）；Query 服务提供 Web UI 和 API，让你按 Trace ID、服务名、标签检索追踪数据。这样的分层设计使各组件可以独立水平扩展——“扫码枪”不会成为“分拣中心”的瓶颈。

从请求产生到查询结果返回，整个链路会产生如下端到端延迟：

$$\displaystyle L_{\text{total}} = L_{\text{sdk}} + L_{\text{agent}} + L_{\text{collector}} + L_{\text{query}}$$

1. L_sdk：应用 SDK 在本地生成、缓冲 Span 的耗时，通常只有几微秒。

$$\displaystyle L_{\text{sdk}} = t_{\text{create}} + t_{\text{buffer}}$$

2. L_agent：Agent 将批量数据通过 UDP/HTTP 转发给 Collector 的网络传输时间。

$$\displaystyle L_{\text{agent}} = t_{\text{flush}} + t_{\text{network}}$$

3. L_collector：Collector 做解包、校验、索引并写存储的处理时间。

$$\displaystyle L_{\text{collector}} = t_{\text{validate}} + t_{\text{index}} + t_{\text{write}}$$

4. L_query：查询时从存储读取并渲染结果的耗时。

$$\displaystyle L_{\text{query}} = t_{\text{search}} + t_{\text{render}}$$

回到快递比喻：扫码枪只负责“扫”，网点分拣中心负责“理”，查询台负责“答”。这种分工让 Jaeger 可以在每层按流量独立扩容，是生产环境中最常用的追踪后端之一。

Tempo架构

与 Jaeger 的“中央分拣”思路不同，Grafana Tempo 更像一家“极简物流公司”：快递员只在前端登记一个运单号，然后把包裹整个扔进仓库，查询时才按运单号去翻货。它的设计哲学是“追踪数据就是大 blob，不做深度索引，只做按 ID 查找”。

Tempo 的核心组件只有四个：Distributor（分发器）、Ingester（预写器）、Querier（查询器）和对象存储后端（S3、GCS、MinIO 等）。请求到达后，Distributor 按 traceID 哈希分片，把数据交给 Ingester 缓冲在内存中，定期刷成 block 写入对象存储。查询时，Querier 先查内存索引或近期 block，再回溯对象存储中的归档数据。

$$\displaystyle \text{Trace}[\text{traceID}] = \text{Lookup}\big(\text{idx}_{\text{recent}} \cup \text{blobs}_{\text{archive}}\big)$$

1. idx_recent：由 Ingester 维护的近期 Trace 索引，覆盖最近数小时的数据。

$$\displaystyle \text{idx}_{\text{recent}} = \{\text{traceID} \to \text{blockID}\}$$

2. blobs_archive：对象存储中长期归档的 block 集合，适合海量冷数据。

$$\displaystyle \text{blobs}_{\text{archive}} = \{b_1, b_2, \ldots, b_m\}$$

3. Lookup(·)：先查索引定位 blockID，再到对应 block 中取出完整 Trace 数据。

Tempo 的选择与 Grafana 生态深度绑定：追踪数据可以直接在 Grafana 中与日志、指标联动。就像你查一年前的快递，虽然要去大仓库翻，但仓库租金便宜，长期保存也不心疼。Tempo 的“按 ID 直查”模型非常适合海量低成本追踪归档。

存储与检索

快递公司每天产生几亿条运单记录，不可能每条都放在快递柜里，更不可能全部无条件永久保存。存储设计决定了追踪系统的成本、查询速度和数据保留能力。分布式追踪的存储策略同样需要在“收入成本”与“查询体验”之间做取舍。

规划存储容量时，有五个关键变量：每秒请求量（QPS）、每条 Trace 的平均 Span 数量、单个 Span 序列化后的平均字节数、数据保留天数、以及采样率。它们相乘，就是一天的存储量。

$$\displaystyle \text{Storage}_{\text{day}} = \text{QPS} \times \overline{\text{spans}} \times \overline{\text{size}} \times 86400 \times r$$

1. QPS：入口服务的每秒请求数，直接决定产生多少条 Trace。

$$\displaystyle \text{QPS} = \frac{N_{\text{requests}}}{T_{\text{seconds}}}$$

2. spans̄：每条 Trace 平均包含的 Span 数量，取决于调用链深度（微服务链路越长数值越大）。

$$\displaystyle \overline{\text{spans}} = \frac{1}{N}\sum_{i=1}^{N} \text{spanCount}_i$$

3. sizē：单个 Span 序列化后的平均字节数，包含属性标签、时间戳等。

$$\displaystyle \overline{\text{size}} = \frac{1}{M}\sum_{j=1}^{M} \text{bytes}_j$$

4. 86400 与 r：一天的秒数；r 为采样率（0~1），二者共同决定实际落库总量。

检索设计上，Jaeger 和 Tempo 都按 traceID 建主索引；若要按服务名/标签搜索，则需要额外的二级索引或依赖外部系统。理解存储公式后你就知道：无脑提高采样率，等于把所有包裹都永久存在市中心仓库，查询只会越来越慢、账单越来越贵。

采样策略

质检部门不可能对每个快递都开箱检查，但也不能什么都不查。分布式追踪面对同样的困境：如果每条请求都全量上报，存储和带宽成本会呈爆炸式增长；如果随机丢弃，又可能恰好丢掉最重要的错误链路。所以需要采样策略。

最简单的方案是头部采样：在请求入口（根 Span 处）按固定概率决定整条链路是否上报。优点是开销极小，缺点是决策“盲人摸象”——不知道请求最终成不成功就直接丢弃，可能漏掉错误链路。更聪明的做法是尾部采样：请求结束后，由收集端根据结果（错误标志、延迟超标、自定义标签）决定哪些 Trace 值得保留。

$$\displaystyle P(\text{保留链路 } i) = \frac{w_i}{\sum_{j=1}^{N} w_j}$$

1. w_i：第 i 条 Trace 的权重，由错误、延迟、标签等特征加权计算。

$$\displaystyle w_i = \alpha \cdot \mathbf{1}[\text{error}] + \beta \cdot \max(0, L_i - L_{\text{thr}})$$

2. Σ w_j：采样窗口内所有候选 Trace 的权重之和，用于归一化概率。

$$\displaystyle \sum_{j=1}^{N} w_j = w_1 + w_2 + \cdots + w_N$$

3. 比值：权重占比越高，该链路被保留的概率越大，从而实现“重点链路全保留、普通链路低概率保留”。

像质检员优先检查投诉多的包裹一样，尾部采样把宝贵的存储资源集中在“最值得复盘”的链路上。生产实践中，头部采样控制总量，尾部采样兜底异常，两者通常搭配使用。

性能优化

快递高峰期，总部要临时增开分拣口、甩挂运输、优先派送时效件。追踪系统在高流量下同样面临“吞吐扛不住、查询乌龟速”的挑战。性能优化的目标，就是在不丢失关键数据的前提下，让上报和查询都快起来。

批量和异步是关键。SDK 端不要每产生一个 Span 就立刻同步发送，而是先在内存缓冲、批量压缩后再上报，大幅减少网络包数量。查询侧则引入并行化：把大查询拆成多个子查询并行执行，最后聚合结果。实际测算优化效果时，延迟分为不可并行的串行部分和可并行的部分：

$$\displaystyle D_{\text{opt}} = D_{\text{serial}} + \frac{D_{\text{parallel}}}{K}$$

1. D_serial：无法并行必须顺序执行的耗时，如单次网络 RTT、磁盘寻址。

$$\displaystyle D_{\text{serial}} = t_{\text{rtt}} + t_{\text{seek}}$$

2. D_parallel：可拆分成子任务并行处理部分的耗时，如扫描多个 block。

$$\displaystyle D_{\text{parallel}} = t_{\text{scan}} + t_{\text{decode}}$$

3. K：并行度，即同时参与查询的协程/线程/机器数量。

$$\displaystyle K = \min(K_{\max}, \text{CPU}_{\text{quota}})$$

4. D_opt：优化后的总延迟；K 越大，并行部分被摊薄得越狠。

在实际部署中，Jaeger 和 Tempo 都支持分区存储：近期热点数据放在 SSD 上，历史归档数据滚动到对象存储。这就像快递公司把热销区包裹放在最近的网点，把过季库存送到郊区仓库——热得快、冷得省。

实践落地

有了追踪平台，运维团队就像装上了“全链路监控大屏”的快递老板：用户投诉派送慢，你能直接看到是揽收慢、干线堵还是派送员绕路。在真实业务中，分布式追踪的落地场景已经非常成熟。

最直接的场景是根因定位：告警系统发现订单接口 P99 延迟飙到 2 秒，工程师打开 Grafana/Tempo 搜出几十条慢 Trace，瀑布图一眼锁定了“库存服务”对某个 Redis 分片的读耗时异常——顺着 Trace 直接找到大 Key 热区。第二个场景是 SLO 统计：分布式追踪天然记录每次请求的真实耗时，可以据此计算服务等级目标的达成率。

$$\displaystyle \text{SLO}_{\text{ratio}} = \frac{\sum_{i=1}^{N} \mathbf{1}[L_i \le L_{\text{threshold}}]}{N} \times 100\%$$

1. 指示函数 1[·]：当第 i 次请求的耗时小于等于阈值时计 1，否则计 0。

$$\displaystyle \mathbf{1}[L_i \le L_{\text{threshold}}] = \begin{cases} 1, & L_i \le L_{\text{threshold}} \\ 0, & \text{otherwise} \end{cases}$$

2. 求和：对所有请求的指示函数值求和，得到满足阈值的请求总数。

$$\displaystyle \sum_{i=1}^{N} \mathbf{1}[L_i \le L_{\text{threshold}}]$$

3. N 与百分比：N 为总请求数，比值乘以 100% 转化为百分比。

第三个场景是容量规划：基于追踪数据统计出各服务调用频率、依赖深度、平均耗时，结合预估 QPS，用存储公式和延迟模型推算所需实例数与大促资源预算。追踪不是炫技，而是让“看得见、查得清、改得准”成为日常——像管理快递网络一样管理你的微服务。

AI 应用场景

Python 演示

import timeimport randomimport json  class Span:    """单个追踪跨度，好比快递中转站的一次扫码记录"""     def __init__(self, span_id, parent_id, service, operation, start, duration):        self.span_id = span_id        self.parent_id = parent_id        self.service = service        self.operation = operation        self.start = start        self.duration = duration     def to_dict(self):        return {            "span_id": self.span_id,            "parent_id": self.parent_id,            "service": self.service,            "operation": self.operation,            "start": round(self.start, 4),            "duration": self.duration,        }  class Tracer:    """模拟 OpenTelemetry Tracer：为一次请求生成一条 Trace"""     def __init__(self, service):        self.service = service        self.trace_id = str(random.randint(10**15, 10**16))        self.spans = []     def start_span(self, operation, parent_id=None):        span_id = str(random.randint(10**8, 10**9))        span = Span(span_id, parent_id, self.service,                    operation, time.time(), 0)        self.spans.append(span)        return span     def end_span(self, span, duration):        span.duration = duration     def export(self):        return {            "trace_id": self.trace_id,            "spans": [s.to_dict() for s in self.spans],        }  def simulate_request():    """模拟一次下单请求：网关 -> 订单服务 -> 支付服务"""    tracer = Tracer(service="api-gateway")    root = tracer.start_span("POST /api/order")    time.sleep(0.001)     order_span = tracer.start_span("order.create", parent_id=root.span_id)    time.sleep(0.002)     pay_span = tracer.start_span("pay.deduct", parent_id=order_span.span_id)    time.sleep(0.003)     tracer.end_span(pay_span, duration=0.004)    tracer.end_span(order_span, duration=0.006)    tracer.end_span(root, duration=0.010)    return tracer.export()  if __name__ == "__main__":    traces = [simulate_request() for _ in range(3)]    print("===== 模拟分布式追踪导出 =====")    for i, trace in enumerate(traces):        print(f"Trace {i + 1}: {trace['trace_id']}")        for s in trace["spans"]:            print(f"  Span {s['span_id']} parent={s['parent_id']} "                  f"{s['service']}@{s['operation']} {s['duration']}s")        print(json.dumps(trace, ensure_ascii=False))

1. class Span:定义单个追踪跨度，对应快递中转站的一次扫码记录。
2. tracer.trace_id = str(random.randint(...))为整条链路生成全局唯一运单号。
3. tracer.start_span("order.create", parent_id=root.span_id)在子服务中创建 Span 并挂到父 Span 下。
4. tracer.end_span(pay_span, duration=0.004)记录耗时，相当于扫码后填上离开时间。
5. tracer.export()把整条 Trace 导出为 JSON，模拟上报给 Jaeger/Tempo。

常见误区

面试题