可观测性平台：Tempo分布式追踪

可视化演示

展示Distributor到Querier的Trace处理流水线、网关订单库存支付微服务调用链诊断、以及Resource到Span的Trace数据模型层级。

追踪基础概念：从运单号到完整轨迹

你寄出的每一件快递外包装上，都贴着一张运单号。这个号码会跟随包裹走过所有分拣中心。每到一个站点，扫描枪“嘀”一声，一条包含时间、站点、操作员的记录就会上传到物流系统。整段旅程的所有记录放在一起，就是这条快递的完整轨迹；而每一条单独的扫码记录，就是轨迹上的一个点。

在微服务架构中，一次用户请求从进入系统到返回响应，会依次调用多个服务。我们把这个完整过程称为 Trace（追踪链路），它对应物流系统中的“完整轨迹”。链路中的每一个服务调用、每一次内部处理，都是一个 Span（跨度），它对应“一次扫码记录”。每个 Span 都携带同一个 Trace ID（追踪标识符），相当于运单号；同时记录自己的 Span ID 和 Parent Span ID，用父级关系把众多 Span 组织成一棵调用树。

下面这个数据结构描述了一个 Span 的灵魂：

如果前端调用网关花了 30ms，网关调用订单服务又花了 80ms，这些数字就像包裹在每站停留的时长。把同一运单号的所有扫码记录按时间轴排开，哪一段拖了后腿就一目了然。Tempo 做的，正是把这张“运单号”对应的全部扫码记录从海量数据中捞出来，拼成一个可读的瀑布图。

Tempo 架构组件：物流中心的分工协作

一个大型物流中心不会只有一个人在干活：有调度员把新到的包裹分派给不同窗口，有前台收件员快速录入信息，有理货员把散装小件合并成整箱，还有查询客服专门应对“我的包裹到哪了”的问题。Tempo 的架构也是同一套分工逻辑。

Tempo 内部由四个核心组件协作完成追踪数据的处理。Distributor（分发器） 是调度员，负责接收上报的 Span 数据，并按规则把属于同一条 Trace 的数据路由到同一个 Ingester（写入器）；Ingester 是前台收件员，负责接收并暂存最新的追踪数据；Compactor（压缩器） 是理货员，定期把小块数据合并成大块，减少存储碎片；Querier（查询器） 是查询客服，响应你输入的 Trace ID 或查询条件，从存储中找回完整链路。

那 Distributor 怎么确保同一条 Trace 的所有 Span 都进入同一个 Ingester 呢？它用了一个非常稳定的哈希算法：

这个设计就好像物流调度员看到同一个运单号就固定分配给同一号收件窗口，这样当你查询时，只需要找那一个窗口就能拿到整段记录，而不必跑遍所有窗口拼凑信息。Ingester 先把数据留在内存，Compactor 后台再去整理归档，职责分离让整个系统忙而不乱。

存储与索引：仓库里的纸箱与门口筛查员

物流仓库里，包裹不会散落一地，而是被装进一个个标准纸箱，按批次码放在货架上。Tempo 的存储设计也遵循同样的思路：它把追踪数据写入 对象存储（S3、GCS、Azure Blob 等），里面以 Block（数据块） 为基本单位组织数据。每个 Block 装着一段时间范围内的很多 Trace，就像一箱装了很多包裹。

但仓库那么大，找一件包裹不能把每个纸箱都拆开翻一遍。Tempo 的做法是：给每个 Block 的门口配一位 Bloom Filter（布隆过滤器）——它不存储具体数据，只回答一个问题：“这个 Trace ID 可能在这个 Block 里吗？”如果回答“不可能”，就跳过整个 Block；如果回答“可能”，再进 Box 里精确查找。

Bloom Filter 的判断逻辑可以这样理解：

这种设计让 Tempo 检索海量 Block 时可以快速跳过绝大多数不相关数据。你输入一个 Trace ID，Tempo 会先查每个 Block 门口的“筛查员”，只对可能包含该 Trace 的 Block 做精确查询。牺牲极小的误判概率，换来数量级的检索加速——这就像仓库门口筛查员如果看到运单号数字特征对不上，直接摆手放行，省去拆箱的工夫。

查询机制：TraceQL 与按 ID 秒查

当客服在物流系统里输入运单号，系统几乎瞬间就能返回结果。Tempo 的查询也分两条路径：如果你知道确切的 Trace ID，那就是“按单号查”，走最快路径；如果你只记得“寄件人、包裹类型、日期”这些模糊信息，就得用高级搜索语句——TraceQL。

TraceQL 是 Tempo 推出的结构化查询语言，让你不用知道 Trace ID 也能筛选链路。它支持按服务名、Span 属性、持续时间等条件过滤。比如你想查“order 服务中耗时超过 100ms 的 Span”，一行 TraceQL 就能表达这种组合条件。查询器拿到条件后，需要扫描哪些 Block、跳过哪些 Block，同样依赖索引和 Bloom Filter 做初步筛选。

一次典型查询的耗时可以被拆解成下面这个量级：

有 Trace ID 时，Tempo 会先把 ID 映射到具体 Block（过程接近 O(1)），再用 Bloom Filter 确认，最后在块内二分定位。整套流程下来，查询通常在几十毫秒内完成。就像客服不用翻遍全城仓库，只凭系统里记录的“运单号在 3 号仓 5 号箱”，直奔目标即可。

Grafana 集成：一张面板看全链路

有了物流系统还不够，用户还得有个方便查看的 App 界面。在可观测性领域，Grafana 就是那个统一的“物流 App”。通过把 Tempo 配置为 Grafana 的数据源，你可以在同一条时间线里把指标（Metrics）、日志（Logs）和追踪（Traces）关联起来——业内称为“三合一可观测性”。

Grafana 里查看 Tempo 数据时，最常见的视图是 瀑布图（Waterfall）：横轴是时间，纵轴是服务调用层级，一层层的 Span 条像瀑布一样铺开，慢 Span 会用醒目的红色标出。你可以从一条 Trace 直接下钻到某个 Span，查看它的标签、日志和耗时详情。反过来，你也能从一条异常日志或一个指标告警，跳转到关联的 Trace 上下文。

这种关联的本质，是让不同信号源共享同一个关联键：

这条公式想表达的是：当你在 Grafana 看到某个服务延迟告警，点击“查看关联 Trace”就能看到该时段对应的完整调用链，再点开具体 Span 就能看到当时打印的日志。追踪不再是孤岛，而是和指标、日志连成一体的作战地图。好比物流 App 上，你既能看运单轨迹，也能看派送员留言，还能看哪个地区的配送整体超时——所有信息围绕同一个运单号组织起来。

OpenTelemetry 采集：贴面单与扫码上传

物流系统能查到轨迹的前提，是每个分拣中心都认真扫码上传。对应到分布式系统，就是每个服务都要主动“埋点”，把自己的处理信息上报给 Tempo。这项采集工作，业界标准方案是 OpenTelemetry。

OpenTelemetry 提供统一的 SDK 和 API，支持 Java、Go、Python、Node.js 等几乎所有主流语言。它会自动拦截服务之间的 HTTP/gRPC 调用，自动生成 Span 并填充 trace_id 和 parent_id，然后通过 OTLP（OpenTelemetry Protocol） 上报到 Tempo。传输方式可选 gRPC 或 HTTP，gRPC 适合内网高性能场景，HTTP 更灵活、便于穿透各种网络环境。

生产环境中，高并发服务的 Span 数量极其庞大。如果每一个请求都完整上报，存储成本会迅速失控。因此 OpenTelemetry 提供了采样机制，最简单的头部采样可以表示为：

采样就像物流公司对“同城速递”只看抽样单：不是每一单都会全程跟踪，而是按照 10% 的比例抽取面单，既保证能发现普遍问题，又不至于让追踪系统的仓库被塞爆。等出了问题，再针对性调高采样率做细查。

性能与优化：控制成本与加速查询

物流公司每天处理几百万个包裹，如果所有扫码记录都原样保存，仓库再大也会爆。Tempo 的优化策略同样围绕两个词：省钱、加速。

省钱的第一招是 压缩。Tempo 使用 Parquet 列式存储格式，把 Span 按列存放，配合压缩算法，可以大幅缩小数据体积。第二招是 Compactor 合并：把大量小 Block 合并成大 Block，减少对象存储的请求次数和元数据开销。第三招是 采样：如前文所述，在采集端控制进水量。加速方面的核心手段是 缓存：Tempo 为热点 Trace 和最近的索引数据维护多级缓存，避免每次查询都去访问慢速对象存储。

数据压缩后的存储成本可以简单估算为：

假设每天产生 100GB 原始 Span，压缩比 5 倍、三副本存储，最终占用约 60GB，成本立减四成。这就像物流公司把散装小包裹合并进标准大箱，同一辆卡车能装更多货物，单位运输成本自然下降。性能优化的本质，就是在“查得快”和“存得省”之间找平衡。

实践与排障：从慢请求到快速定位

现在我们把所有知识拼到一起，完成一次真实的排障演练。某天线上监控突然告警：下单接口 P99 延迟从 200ms 飙升到 1.2s。你打开 Grafana，先看指标面板确认异常时段，然后定位到几条典型的慢 Trace，点开瀑布图，发现“支付服务”对应的 Span 耗时占了整条链路的 70%。

进一步下钻，你发现该 Span 内部调用了一个外部 HTTP 接口，而这条调用在 Trace 中显示为“下游超时重试了 3 次”。整个过程不到 5 分钟，这就是成熟追踪平台带来的排障效率。为保障这种效率持续有效，团队应该制定追踪系统的 SLO（服务等级目标）：

实践中，团队还会配置“高延迟 Span 告警”：当某个 Span 耗时超过阈值时，自动在 Grafana 中弹出告警并附上对应 Trace 的链接。这样即使不是每个人都会用 TraceQL 写复杂查询，也能顺着告警一键跳转完成定位。复盘时，把高频问题沉淀成最佳实践文档，物流系统才会越用越顺。

AI 应用场景

Python 演示

"""模拟 Tempo 分布式追踪的简化流程：生成链路、写入块、按 Trace ID 查询"""import randomimport time  class Span:    def __init__(self, trace_id, span_id, parent_id, service, start_ms, dur_ms):        self.trace_id = trace_id        self.span_id = span_id        self.parent_id = parent_id        self.service = service        self.start_ms = start_ms        self.dur_ms = dur_ms  class BloomFilter:    def __init__(self, size, k):        self.size = size        self.k = k        self.bits = [0] * size     def put(self, key):        for seed in range(self.k):            self.bits[hash((key, seed)) % self.size] = 1     def maybe_contains(self, key):        return all(self.bits[hash((key, seed)) % self.size] for seed in range(self.k))  def generate_trace(trace_id, services):    spans = []    root = Span(trace_id, trace_id + "-s1", "", services[0], 0, random.randint(20, 80))    spans.append(root)    parent = root    for i, svc in enumerate(services[1:], start=2):        s = Span(trace_id, trace_id + "-s" + str(i), parent.span_id, svc,                 parent.start_ms + random.randint(0, 10), random.randint(10, 60))        spans.append(s)        parent = s    return spans  class TempoLike:    def __init__(self):        self.blocks = {}        self.bloom = BloomFilter(1024, 3)     def ingest(self, spans):        trace_id = spans[0].trace_id        self.blocks[trace_id] = spans        self.bloom.put(trace_id)     def query(self, trace_id):        if not self.bloom.maybe_contains(trace_id):            return []        return self.blocks.get(trace_id, [])  def main():    tempo = TempoLike()    for i in range(20):        tid = "trace-%03d" % i        spans = generate_trace(tid, ["frontend", "gateway", "order", "pay"])        tempo.ingest(spans)        time.sleep(0.01)     tid = "trace-007"    result = tempo.query(tid)    print("查询 %s 返回 %d 个 Span：" % (tid, len(result)))    for s in result:        print("  %-10s <- %-10s %-8s %dms+%dms" % (s.span_id, s.parent_id, s.service, s.start_ms, s.dur_ms))  if __name__ == "__main__":    main()

1. class Span:定义追踪数据的最小单元，包含 trace_id、span_id、parent_id 和耗时信息，对应正文中的 Span 数据结构。
2. class BloomFilter:用位数组模拟 Tempo 的 Block 预筛机制，maybe_contains 快速回答“可能在里面吗”。
3. generate_trace()模拟一次请求经过多个微服务，自动生成一条带父子关系的调用树。
4. tempo.ingest(spans)模拟 Distributor 和 Ingster 的写入过程，将整条 Trace 存入 Block 并更新索引。
5. tempo.query(trace_id)先通过 Bloom Filter 预筛，再精确查询返回完整链路。

常见误区

面试题