【系统架构设计百科】分布式追踪：OpenTelemetry 与全链路可观测

上周五晚上十点，某支付平台的值班工程师收到告警：支付成功率从 99.97% 跌到 98.2%。他打开 Grafana 看到延迟指标飙升，但指标只能告诉他”慢了”，不能告诉他”哪条链路慢、卡在哪个服务、是哪种请求类型”。他翻日志，三个服务的日志分散在不同的 Elasticsearch 索引里，用订单号手动关联了二十分钟才拼出一条完整调用链：API 网关 -> 风控服务 -> 支付路由 -> 银行通道。最后发现是银行通道的连接池耗尽导致超时，平均修复时间（MTTR）超过四十分钟。

如果这套系统接入了分布式追踪（Distributed Tracing），整个排查过程可以压缩到三分钟：打开 Jaeger 或 Tempo，按错误状态过滤，点开一条异常 Trace，火焰图直接标红超时的 Span，根因一目了然。

这篇文章要回答一个被反复争论的问题：分布式追踪的采样率设多少？100% 采样的成本和收益分别是什么？ 围绕这个核心问题，我们会从 Dapper 论文的基础概念讲起，拆解 W3C Trace Context 标准、OpenTelemetry 的三层架构、Jaeger 与 Tempo 的存储设计差异、采样策略的工程取舍，以及追踪数据驱动的自动拓扑发现。

上一篇：指标体系架构 | 下一篇：告警策略设计

一、从 Dapper 到 OpenTelemetry：分布式追踪的演进

1.1 Dapper 论文的三个核心概念

2010 年，Google 发表了 Dapper 论文（“Dapper, a Large-Scale Distributed Systems Tracing Infrastructure”），奠定了现代分布式追踪的理论基础。论文定义了三个核心概念：

追踪（Trace）：一次完整的端到端请求在分布式系统中的执行路径。一个 Trace 由一棵 Span 树组成，根节点是用户发起请求的入口点。

跨度（Span）：Trace 中的一个工作单元，通常对应一次 RPC 调用、一次数据库查询或一次消息消费。每个 Span 包含以下核心字段：

• Trace ID：全局唯一标识符，同一条调用链上的所有 Span 共享同一个 Trace ID
• Span ID：当前 Span 的唯一标识符
• Parent Span ID：父 Span 的标识符，用于构建树形结构
• Operation Name：操作名称，如 POST /api/payment
• Start Time / Duration：开始时间和持续时长
• Tags / Attributes：键值对形式的元数据，如 http.status_code=200
• Events / Logs：Span 生命周期内的离散事件，如 “connection pool exhausted”
• Status：成功、错误或未设置

上下文传播（Context Propagation）：将 Trace ID 和 Span ID 从一个服务传递到下一个服务的机制。这是分布式追踪能工作的前提——没有上下文传播，每个服务只能看到自己的局部视图，无法拼出完整的调用链。

1.2 追踪系统的代际演进

分布式追踪工具经历了三代演进：

第一代（2012-2016）：各家自研或使用早期开源方案。Twitter 的 Zipkin（2012）是第一个广泛使用的开源追踪系统，借鉴了 Dapper 的设计。Uber 开发了 Jaeger（2015），增加了自适应采样等特性。这一代的问题是每个工具有自己的 SDK 和数据格式，换一个后端就要改代码。

第二代（2016-2019）：OpenTracing（2016）和 OpenCensus（2018）试图通过标准化 API 解耦 SDK 与后端。OpenTracing 由 CNCF 托管，提供厂商无关的追踪 API。OpenCensus 由 Google 发起，同时覆盖追踪和指标。但两个标准并存本身就是问题——开发者不知道该选哪个，库作者被迫同时适配两个 SDK。

第三代（2019-至今）：OpenTelemetry（OTel）合并了 OpenTracing 和 OpenCensus，成为 CNCF 的旗舰项目。它提供统一的 API、SDK 和 Collector，覆盖追踪（Traces）、指标（Metrics）和日志（Logs）三大信号。截至 2025 年，OpenTelemetry 已经是 Kubernetes 之后 CNCF 活跃度第二高的项目，几乎所有主流语言都有生产就绪的 SDK。

1.3 OpenTelemetry 的三层架构

OpenTelemetry 的架构分为三层：

应用层              采集层                     存储/分析层
+-----------+      +----------------+        +------------+
| OTel SDK  | ---> | OTel Collector | -----> | Jaeger     |
| (自动/手动 |      | (Receiver /    |        | Tempo      |
|  埋点)     |      |  Processor /   |        | Zipkin     |
+-----------+      |  Exporter)     |        | Datadog    |
                   +----------------+        +------------+

SDK 层：嵌入应用进程，负责生成 Span、注入/提取上下文、执行采样决策。SDK 提供两种埋点模式：

• 自动埋点（Auto-instrumentation）：通过字节码注入（Java Agent）、猴子补丁（Python）或编译时插桩，自动为常见框架（gRPC、HTTP、数据库驱动）生成 Span，零代码改动。
• 手动埋点（Manual instrumentation）：开发者显式调用 API 创建 Span，添加自定义属性和事件，适用于业务逻辑追踪。

Collector 层：独立部署的数据管道，职责是接收、处理和导出遥测数据。Collector 的三大组件：

• Receiver（接收器）：支持 OTLP（OpenTelemetry Protocol）、Jaeger、Zipkin 等多种协议的数据接入
• Processor（处理器）：批量处理（Batch）、采样过滤（Tail Sampling）、属性修改（Attributes）、资源检测（Resource Detection）
• Exporter（导出器）：将处理后的数据发送到 Jaeger、Tempo、Datadog、Elasticsearch 等后端

存储/分析层：负责持久化存储和查询分析，这部分我们在后续章节详细展开。

二、W3C Trace Context 标准：跨服务的上下文传播

2.1 为什么需要标准化

在 W3C Trace Context 之前，每个追踪系统用自己的 Header 传播上下文：

• Zipkin 用 X-B3-TraceId、X-B3-SpanId、X-B3-ParentSpanId、X-B3-Sampled 四个 Header
• Jaeger 用 uber-trace-id 单个 Header
• AWS X-Ray 用 X-Amzn-Trace-Id
• Datadog 用 x-datadog-trace-id

当一条请求链路跨越使用不同追踪系统的服务时，上下文传播就断了。服务 A 用 Jaeger，服务 B 用 Zipkin，中间经过一个第三方 API 网关——三种 Header 格式互不认识，一条 Trace 被割裂成三段。

W3C Trace Context 标准（2020 年进入 W3C Recommendation 状态）通过定义统一的 HTTP Header 格式解决了这个问题。

2.2 traceparent Header 格式

traceparent 是 W3C Trace Context 的核心 Header，格式如下：

traceparent: {version}-{trace-id}-{parent-id}-{trace-flags}

各字段含义：

一个实际的 traceparent Header 示例：

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

解读：

• 版本 00
• Trace ID 4bf92f3577b34da6a3ce929d0e0e4736
• Parent ID（当前 Span ID）00f067aa0ba902b7
• trace-flags 01，表示已采样（sampled）

2.3 tracestate Header

tracestate 是一个可选的 Header，用于携带厂商特定的追踪信息。它的设计哲学是：traceparent 保证互操作性，tracestate 保留厂商扩展能力。

tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE

格式是逗号分隔的键值对列表，每个键值对用等号连接。键名通常是厂商标识符。规范要求：

• 中间代理必须原样转发 tracestate，即使不理解其中的内容
• 如果一个厂商需要修改自己的值，它把自己的键值对移到列表最前面
• 最多 32 个键值对，总长度不超过 512 字节

2.4 上下文传播的实现机制

上下文传播在不同通信协议中的实现方式不同：

HTTP：通过 traceparent 和 tracestate Header。OpenTelemetry SDK 的 TextMapPropagator 负责注入和提取。

gRPC：通过 Metadata（等价于 HTTP Header）传播，格式与 HTTP 相同。

消息队列：Kafka、RabbitMQ 等通过消息头（Message Headers）传播。需要注意消息队列的异步特性——消费者处理消息时，生产者的 Span 可能已经结束。

数据库：某些数据库（如 PostgreSQL 的 /*traceparent=...*/ SQL 注释）支持在查询中携带追踪上下文，用于关联应用层 Span 和数据库层的查询计划。

以下是一个 Go 语言中手动传播上下文的示例：

package main

import (
    "context"
    "net/http"

    "go.opentelemetry.io/otel"
    "go.opentelemetry.io/otel/propagation"
)

// 发送端：将追踪上下文注入到 HTTP 请求的 Header 中
func makeRequest(ctx context.Context, url string) (*http.Response, error) {
    req, err := http.NewRequestWithContext(ctx, "GET", url, nil)
    if err != nil {
        return nil, err
    }

    // 注入 traceparent 和 tracestate 到请求 Header
    otel.GetTextMapPropagator().Inject(ctx, propagation.HeaderCarrier(req.Header))

    return http.DefaultClient.Do(req)
}

// 接收端：从 HTTP 请求的 Header 中提取追踪上下文
func handleRequest(w http.ResponseWriter, r *http.Request) {
    // 从请求 Header 中提取 traceparent 和 tracestate
    ctx := otel.GetTextMapPropagator().Extract(r.Context(), propagation.HeaderCarrier(r.Header))

    // 基于提取的上下文创建子 Span
    tracer := otel.Tracer("payment-service")
    ctx, span := tracer.Start(ctx, "process-payment")
    defer span.End()

    // 业务逻辑...
    callDownstreamService(ctx)
}

2.5 跨边界传播的陷阱

工程实践中，上下文传播有几个常见的坑：

异步处理的上下文丢失：当请求被放入队列异步处理时，如果不显式传播上下文，Trace 就会在队列处断开。解决方案是将 traceparent 写入消息头，消费者启动新 Span 时用提取的上下文作为父上下文。

线程池的上下文泄漏：Java 中使用线程池时，ThreadLocal 存储的上下文可能泄漏到其他请求。OpenTelemetry Java SDK 提供了 Context.wrap() 方法来安全地跨线程传播上下文。

批处理的上下文关联：一个批处理任务可能聚合了多个请求的数据，此时不应简单地沿用某一个请求的 Trace ID。正确做法是创建一个新的 Trace，通过 Span Link 关联到原始请求的 Trace。

三、OpenTelemetry SDK 埋点实战

3.1 Java 自动埋点

Java 是 OpenTelemetry 自动埋点支持最成熟的语言。通过 Java Agent（-javaagent 参数）实现字节码注入，无需修改应用代码即可为 Spring Boot、gRPC、JDBC、Netty 等框架生成 Span。

# 下载 OpenTelemetry Java Agent
curl -L -o opentelemetry-javaagent.jar \
  https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/latest/download/opentelemetry-javaagent.jar

# 启动应用，配置导出目标为 OTel Collector
java -javaagent:opentelemetry-javaagent.jar \
  -Dotel.service.name=payment-service \
  -Dotel.exporter.otlp.endpoint=http://otel-collector:4317 \
  -Dotel.traces.sampler=parentbased_traceidratio \
  -Dotel.traces.sampler.arg=0.1 \
  -jar payment-service.jar

关键配置项说明：

Java 手动埋点示例，为关键业务逻辑添加自定义 Span：

import io.opentelemetry.api.GlobalOpenTelemetry;
import io.opentelemetry.api.trace.Span;
import io.opentelemetry.api.trace.StatusCode;
import io.opentelemetry.api.trace.Tracer;
import io.opentelemetry.context.Scope;

public class PaymentProcessor {
    private static final Tracer tracer =
        GlobalOpenTelemetry.getTracer("payment-processor", "1.0.0");

    public PaymentResult processPayment(PaymentRequest request) {
        Span span = tracer.spanBuilder("process-payment")
            .setAttribute("payment.amount", request.getAmount())
            .setAttribute("payment.currency", request.getCurrency())
            .setAttribute("payment.method", request.getMethod())
            .startSpan();

        try (Scope scope = span.makeCurrent()) {
            // 风控检查
            RiskResult risk = checkRisk(request);
            span.addEvent("risk-check-completed",
                io.opentelemetry.api.common.Attributes.of(
                    io.opentelemetry.api.common.AttributeKey.stringKey("risk.level"),
                    risk.getLevel()
                ));

            if (risk.isRejected()) {
                span.setStatus(StatusCode.ERROR, "payment rejected by risk check");
                return PaymentResult.rejected(risk.getReason());
            }

            // 调用银行通道
            BankResponse response = callBankChannel(request);
            span.setAttribute("bank.channel", response.getChannel());
            span.setAttribute("bank.response_code", response.getCode());

            return PaymentResult.success(response.getTransactionId());
        } catch (Exception e) {
            span.setStatus(StatusCode.ERROR, e.getMessage());
            span.recordException(e);
            throw e;
        } finally {
            span.end();
        }
    }
}

3.2 Python 埋点

Python 通过 opentelemetry-instrument 命令实现自动埋点，底层使用猴子补丁（Monkey Patching）替换标准库和第三方库的关键函数。

# 安装 OpenTelemetry Python SDK 和自动埋点包
pip install opentelemetry-api \
    opentelemetry-sdk \
    opentelemetry-exporter-otlp \
    opentelemetry-instrumentation-flask \
    opentelemetry-instrumentation-requests \
    opentelemetry-instrumentation-sqlalchemy

# 自动埋点启动
opentelemetry-instrument \
    --service_name order-service \
    --exporter_otlp_endpoint http://otel-collector:4317 \
    --traces_exporter otlp \
    python app.py

手动埋点示例：

from opentelemetry import trace
from opentelemetry.trace import StatusCode

tracer = trace.get_tracer("order-service", "1.0.0")

def create_order(user_id: str, items: list[dict]) -> dict:
    with tracer.start_as_current_span("create-order") as span:
        span.set_attribute("user.id", user_id)
        span.set_attribute("order.item_count", len(items))

        # 库存检查
        with tracer.start_as_current_span("check-inventory") as inv_span:
            available = inventory_service.check(items)
            inv_span.set_attribute("inventory.all_available", available)
            if not available:
                span.set_status(StatusCode.ERROR, "insufficient inventory")
                raise InsufficientInventoryError()

        # 价格计算
        with tracer.start_as_current_span("calculate-price") as price_span:
            total = pricing_service.calculate(items, user_id)
            price_span.set_attribute("order.total_amount", total)

        # 写入数据库
        with tracer.start_as_current_span("persist-order") as db_span:
            db_span.set_attribute("db.system", "postgresql")
            db_span.set_attribute("db.operation", "INSERT")
            order = order_repository.save(user_id, items, total)

        span.set_attribute("order.id", order["id"])
        return order

3.3 Go 埋点

Go 的 OpenTelemetry SDK 不支持自动埋点（Go 没有运行时字节码注入机制），所有埋点都需要手动完成或使用官方提供的中间件库。

package main

import (
    "context"
    "log"
    "net/http"

    "go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp"
    "go.opentelemetry.io/otel"
    "go.opentelemetry.io/otel/attribute"
    "go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc"
    "go.opentelemetry.io/otel/sdk/resource"
    sdktrace "go.opentelemetry.io/otel/sdk/trace"
    semconv "go.opentelemetry.io/otel/semconv/v1.21.0"
)

func initTracer() (*sdktrace.TracerProvider, error) {
    exporter, err := otlptracegrpc.New(context.Background(),
        otlptracegrpc.WithEndpoint("otel-collector:4317"),
        otlptracegrpc.WithInsecure(),
    )
    if err != nil {
        return nil, err
    }

    tp := sdktrace.NewTracerProvider(
        sdktrace.WithBatcher(exporter),
        sdktrace.WithResource(resource.NewWithAttributes(
            semconv.SchemaURL,
            semconv.ServiceNameKey.String("user-service"),
            semconv.ServiceVersionKey.String("1.0.0"),
        )),
        // 头部采样：10% 概率采样
        sdktrace.WithSampler(sdktrace.ParentBased(
            sdktrace.TraceIDRatioBased(0.1),
        )),
    )

    otel.SetTracerProvider(tp)
    return tp, nil
}

func main() {
    tp, err := initTracer()
    if err != nil {
        log.Fatal(err)
    }
    defer tp.Shutdown(context.Background())

    tracer := otel.Tracer("user-service")

    // 使用 otelhttp 中间件自动为 HTTP Handler 创建 Span
    handler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        ctx := r.Context()

        // 手动创建子 Span
        ctx, span := tracer.Start(ctx, "fetch-user-profile")
        defer span.End()

        span.SetAttributes(
            attribute.String("user.id", r.URL.Query().Get("id")),
            attribute.String("db.system", "postgresql"),
        )

        // 业务逻辑...
        profile, err := getUserProfile(ctx, r.URL.Query().Get("id"))
        if err != nil {
            span.RecordError(err)
            http.Error(w, "internal error", 500)
            return
        }

        writeJSON(w, profile)
    })

    wrappedHandler := otelhttp.NewHandler(handler, "GET /api/users")
    log.Fatal(http.ListenAndServe(":8080", wrappedHandler))
}

四、OpenTelemetry Collector 架构与部署

4.1 Collector 的管道模型

Collector 的核心设计是管道（Pipeline）模型：数据从 Receiver 进入，经过一组 Processor 处理，最终由 Exporter 发出。一个 Collector 实例可以同时运行多条管道，互不干扰。

# otel-collector-config.yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  jaeger:
    protocols:
      thrift_http:
        endpoint: 0.0.0.0:14268

processors:
  batch:
    send_batch_size: 8192
    timeout: 5s
  memory_limiter:
    check_interval: 1s
    limit_mib: 2048
    spike_limit_mib: 512
  tail_sampling:
    decision_wait: 10s
    num_traces: 100000
    policies:
      - name: error-policy
        type: status_code
        status_code:
          status_codes: [ERROR]
      - name: latency-policy
        type: latency
        latency:
          threshold_ms: 1000
      - name: probabilistic-policy
        type: probabilistic
        probabilistic:
          sampling_percentage: 5

exporters:
  otlp/tempo:
    endpoint: tempo:4317
    tls:
      insecure: true
  otlp/jaeger:
    endpoint: jaeger-collector:4317
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp, jaeger]
      processors: [memory_limiter, tail_sampling, batch]
      exporters: [otlp/tempo]

4.2 部署模式

Collector 有三种典型的部署模式：

Sidecar 模式：每个应用 Pod 旁边部署一个 Collector 容器。优点是采集粒度细、故障隔离好；缺点是资源开销大——每个 Pod 额外消耗 50-200MB 内存。

DaemonSet 模式：每个 Kubernetes 节点部署一个 Collector。应用通过 localhost:4317 发送数据，网络开销最小。这是最常用的部署模式。

Gateway 模式：集中部署一组 Collector 实例，所有应用通过负载均衡器发送数据。适合需要集中执行尾部采样的场景——尾部采样需要看到同一个 Trace 的所有 Span 才能做决策，而 DaemonSet 模式下 Span 分散在不同节点的 Collector 上。

实际生产环境通常组合使用：DaemonSet 层做预处理和批量化，Gateway 层做尾部采样和路由分发。

                                      +---------------------+
+-------+    +----------+            |   Gateway Collector  |    +---------+
| App 1 | -> | DaemonSet|            |   (尾部采样)          | -> | Tempo   |
+-------+    | Collector| ---------> |                     |    +---------+
+-------+    | (预处理)  |            +---------------------+
| App 2 | -> |          |
+-------+    +----------+

4.3 Collector 的性能调优

几个关键的性能参数：

Batch Processor 的 send_batch_size 和 timeout：批量大小越大，网络效率越高，但延迟也越高。生产环境通常设置 send_batch_size: 8192、timeout: 5s。

Memory Limiter 的 limit_mib：防止 Collector 因突发流量耗尽内存。当内存使用超过阈值时，Collector 会拒绝新数据并返回背压信号（gRPC UNAVAILABLE）。

队列大小：Exporter 支持配置发送队列（sending_queue），用于应对后端存储的短暂不可用。队列会持久化到磁盘，避免数据丢失。

exporters:
  otlp/tempo:
    endpoint: tempo:4317
    sending_queue:
      enabled: true
      num_consumers: 10
      queue_size: 10000
      storage: file_storage/otlp
    retry_on_failure:
      enabled: true
      initial_interval: 5s
      max_interval: 30s
      max_elapsed_time: 300s

五、Jaeger 与 Tempo 的存储架构

5.1 Jaeger 的存储设计

Jaeger 最初由 Uber 在 2015 年开发，是最早的 OpenTracing 兼容追踪系统之一。其存储层支持多种后端：

Cassandra：Jaeger 的第一个生产存储后端。Cassandra 的宽列模型（Wide Column）天然适合追踪数据的写入模式——同一个 Trace 的 Span 写入同一个 Partition，按时间排序。查询时通过 Trace ID 精确定位 Partition，读取性能好。但 Cassandra 的二级索引能力弱，按服务名、操作名搜索 Trace 需要额外维护索引表，这是 Jaeger 在 Cassandra 上最大的架构痛点。

Elasticsearch：Jaeger 引入 Elasticsearch 主要是为了解决搜索问题。Elasticsearch 的倒排索引天然支持按任意标签搜索 Trace，查询灵活度远超 Cassandra。代价是写入吞吐量较低，存储成本较高（JSON 格式膨胀 + 索引占用）。

Kafka + Flink（Jaeger 的流式处理模式）：Span 先写入 Kafka，由 Flink/Spark 任务消费后写入最终存储。这种架构用于需要在写入前做数据增强（如关联 Pod 元数据）或尾部采样的场景。

Jaeger 的数据模型围绕 Trace 和 Span 组织：

{
  "traceID": "4bf92f3577b34da6a3ce929d0e0e4736",
  "spans": [
    {
      "spanID": "00f067aa0ba902b7",
      "operationName": "POST /api/payment",
      "references": [
        {
          "refType": "CHILD_OF",
          "traceID": "4bf92f3577b34da6a3ce929d0e0e4736",
          "spanID": "a1b2c3d4e5f60718"
        }
      ],
      "startTime": 1700000000000000,
      "duration": 45230,
      "tags": [
        {"key": "http.method", "type": "string", "value": "POST"},
        {"key": "http.status_code", "type": "int64", "value": 200},
        {"key": "span.kind", "type": "string", "value": "server"}
      ],
      "logs": [
        {
          "timestamp": 1700000000010000,
          "fields": [
            {"key": "event", "type": "string", "value": "risk-check-passed"}
          ]
        }
      ],
      "process": {
        "serviceName": "payment-service",
        "tags": [
          {"key": "hostname", "type": "string", "value": "payment-pod-7d8f9"}
        ]
      }
    }
  ]
}

5.2 Grafana Tempo 的存储设计

Tempo 是 Grafana Labs 在 2020 年推出的追踪后端，设计哲学与 Jaeger 截然不同：只做 Trace ID 查询，不建索引。

这个设计决策背后的逻辑是：追踪数据的主要访问模式是”拿到 Trace ID 后查看完整 Trace”，而 Trace ID 通常来自日志或指标中的关联字段。既然如此，为什么要花大量资源为 Span 的每个标签建倒排索引？

Tempo 的存储架构：

                                  +------------------+
接收 OTLP 数据                     |  对象存储          |
+----------+    +----------+     | (S3 / GCS / Azure)|
| Ingester | -> | Compactor| --> | Parquet 列式格式    |
+----------+    +----------+     +------------------+
      |
      v
+----------+
| WAL 磁盘  |
+----------+

Ingester：接收 Span 数据，在内存中按 Trace ID 聚合，然后写入本地 WAL（Write-Ahead Log）。当一个 Trace 的所有 Span 到齐（或超时）后，整个 Trace 被刷到对象存储。

对象存储：Tempo 用 S3、GCS 或 Azure Blob Storage 作为持久存储。数据以 Parquet 列式格式存储，按时间窗口组织成 Block。每个 Block 包含一个 Bloom Filter 索引，用于快速判断某个 Trace ID 是否在该 Block 中。

Compactor：后台任务，负责合并小 Block 为大 Block，清理过期数据，重建 Bloom Filter。

Tempo 的成本优势来自两点：

1. 对象存储的单价远低于 Elasticsearch 或 Cassandra 的计算+存储成本
2. 不建倒排索引，写入路径极简，CPU 和内存开销低

代价是 Tempo 原生不支持按标签搜索——你不能直接搜索”所有 http.status_code=500 的 Trace”。为了弥补这个缺陷，Tempo 从 2.0 版本开始引入了 TraceQL 查询语言和基于 Parquet 的搜索能力，但性能仍然无法与 Elasticsearch 的倒排索引相比。

5.3 Jaeger 与 Tempo 的对比

5.4 Zipkin 简要对比

Zipkin 是最早的开源追踪系统，架构相对简单。它支持 MySQL、Cassandra、Elasticsearch 作为存储后端，查询能力与 Jaeger + ES 类似。Zipkin 的优势是部署简单、社区成熟；劣势是功能迭代较慢，缺乏自适应采样等高级特性。在新建系统中，Zipkin 正逐步被 Jaeger 和 Tempo 取代。

六、采样策略：100% 采样值不值得

这是分布式追踪中争议最大的工程决策之一。我们逐一分析各种采样策略的机制和取舍。

6.1 头部采样（Head-based Sampling）

头部采样在请求进入系统的入口点（通常是 API 网关或第一个服务）做出采样决策，决策结果通过 traceparent 的 trace-flags 位传播到所有下游服务。

请求到达入口
    |
    v
掷骰子：随机数 < 采样率？
    |             |
   是            否
    |             |
 采样=1         采样=0
    |             |
 记录所有 Span   丢弃所有 Span

优点：

• 实现简单，SDK 内置支持
• 采样决策一致性好——同一个 Trace 的所有 Span 要么全采，要么全丢
• 对下游服务无额外要求

缺点：

• 在入口处做决策时，还不知道这个请求会不会出错、会不会慢。一个采样率 1% 的系统，99% 的错误请求被丢弃了——恰恰是最有价值的数据。

6.2 尾部采样（Tail-based Sampling）

尾部采样在 Trace 完成后（所有 Span 都到齐后）才做采样决策。这意味着可以根据 Trace 的完整信息来决定是否保留——比如保留所有包含错误的 Trace、保留所有延迟超过 P99 的 Trace。

所有 Span 到齐
    |
    v
分析完整 Trace：
  - 有错误？ -> 100% 保留
  - 延迟 > 1s？ -> 100% 保留
  - 正常请求？ -> 5% 概率保留
    |
    v
写入存储 / 丢弃

尾部采样通常在 OTel Collector 的 Gateway 模式中实现（tail_sampling Processor）。实现要点：

• Trace 聚合：Collector 需要在内存中缓存 Span，等待同一个 Trace 的所有 Span 到齐。decision_wait 参数控制等待时间，通常设为 10-30 秒。
• 路由一致性：同一个 Trace 的所有 Span 必须路由到同一个 Collector 实例，否则无法聚合。这要求在 Collector 前面加一个基于 Trace ID 的一致性哈希负载均衡器。
• 内存压力：高 QPS 系统中，Collector 需要同时缓存大量未完成的 Trace。num_traces 参数限制缓存数量，超出后强制决策。

6.3 自适应采样（Adaptive Sampling）

Jaeger 原生支持自适应采样（Adaptive Sampling），思路是根据每个服务、每个端点的流量动态调整采样率：

• 高流量端点（如健康检查）降低采样率
• 低流量端点（如管理员操作）提高采样率
• 目标是每个端点每秒保留固定数量的 Trace（如每秒 2 条）

端点: GET /health     流量: 10000 QPS  -> 采样率: 0.02% (2/10000)
端点: POST /payment   流量: 100 QPS    -> 采样率: 2%    (2/100)
端点: DELETE /admin   流量: 1 QPS      -> 采样率: 100%  (2/1, 上限100%)

这种策略在保证覆盖率的同时控制了总数据量。Jaeger 的实现是 Collector 定期计算各端点的采样率，通过 Agent 下发给 SDK。

6.4 Always-on（100% 采样）的成本与收益

收益：

1. 不丢失任何异常 Trace：头部采样在 1% 采样率下会丢弃 99% 的错误请求，100% 采样保证所有异常都可追踪
2. 精确的延迟分布：P99、P999 等尾延迟指标需要大量样本才有统计意义，低采样率下的延迟分布是失真的
3. 追踪驱动的指标生成：从 100% 的 Trace 数据中聚合出 RED 指标（Rate、Error、Duration），比从采样数据推算更准确
4. 关键路径分析：自动识别每条请求的关键路径需要完整的 Trace 数据
5. 自动拓扑发现：从 Trace 数据中构建服务依赖图，采样率越高，拓扑图越完整

成本：

假设一个中等规模的微服务系统：

• 50 个服务
• 入口 QPS 10000
• 平均每个请求产生 8 个 Span
• 每个 Span 约 500 字节

100% 采样的数据量：

10000 QPS x 8 Span/请求 x 500 字节/Span = 40 MB/s = 3.4 TB/天

如果用 Elasticsearch 存储（索引膨胀约 3 倍），实际存储开销约 10 TB/天。保留 14 天需要 140 TB 的 SSD 存储——这是一笔显著的基础设施费用。

如果用 Tempo + S3 对象存储，成本可以降低一个数量级：

Tempo 存储（Parquet 格式，压缩比约 5:1）
3.4 TB/天 / 5 = 680 GB/天
保留 30 天 = 20 TB
S3 标准存储单价约 $0.023/GB/月
月存储成本 ≈ 20000 x $0.023 ≈ $460/月

加上 Ingester、Compactor 的计算资源和网络传输费用，总成本约 $2000-5000/月——对于一个中等规模的系统来说是可接受的。

结论：100% 采样在技术上是可行的，关键在于选择合适的存储后端。如果用 Elasticsearch，100% 采样的成本可能不可接受；如果用 Tempo + 对象存储，成本可以控制在合理范围内。

6.5 采样策略对比表

生产环境推荐的混合策略：

1. SDK 层（头部）：100% 通过，不做任何丢弃
2. DaemonSet Collector 层：预处理、批量化，但不做采样
3. Gateway Collector 层：尾部采样——错误和慢请求 100% 保留，正常请求按端点自适应采样
4. 存储层：用 Tempo + 对象存储，长期保留低成本

七、追踪数据驱动的自动拓扑发现

7.1 服务依赖图的构建

追踪数据天然包含服务间的调用关系：每个 Span 记录了调用方（Client Span）和被调用方（Server Span）。从大量 Trace 中聚合这些关系，就能自动构建服务依赖图（Service Dependency Graph）。

graph LR
    A[API 网关] -->|HTTP| B[订单服务]
    A -->|HTTP| C[用户服务]
    B -->|gRPC| D[库存服务]
    B -->|gRPC| E[支付服务]
    B -->|Kafka| F[通知服务]
    E -->|HTTP| G[银行通道]
    D -->|SQL| H[(库存数据库)]
    B -->|SQL| I[(订单数据库)]
    C -->|SQL| J[(用户数据库)]
    E -->|Redis| K[(支付缓存)]

这个拓扑图不是手动维护的，是从 Trace 数据中实时聚合出来的。Jaeger 的 “Dependencies” 页面和 Tempo 的 “Service Graph” 都提供了这个能力。

构建算法的核心逻辑：

from collections import defaultdict

def build_dependency_graph(traces: list[dict]) -> dict:
    """从 Trace 数据中构建服务依赖图"""
    edges = defaultdict(lambda: {"call_count": 0, "error_count": 0, "avg_duration_ms": 0})

    for trace in traces:
        spans_by_id = {s["spanID"]: s for s in trace["spans"]}

        for span in trace["spans"]:
            if not span.get("references"):
                continue

            parent_id = span["references"][0]["spanID"]
            parent = spans_by_id.get(parent_id)
            if not parent:
                continue

            caller = parent["process"]["serviceName"]
            callee = span["process"]["serviceName"]

            if caller == callee:
                continue

            key = f"{caller} -> {callee}"
            edges[key]["call_count"] += 1
            edges[key]["avg_duration_ms"] += span["duration"] / 1000

            if any(t["key"] == "error" and t["value"] == True
                   for t in span.get("tags", [])):
                edges[key]["error_count"] += 1

    # 计算平均延迟
    for key in edges:
        if edges[key]["call_count"] > 0:
            edges[key]["avg_duration_ms"] /= edges[key]["call_count"]

    return dict(edges)

7.2 关键路径分析（Critical Path Analysis）

一条 Trace 的总延迟不等于所有 Span 延迟之和——并行调用的 Span 只有最慢的那个在关键路径上。关键路径分析（Critical Path Analysis）的目标是找出决定端到端延迟的那条最长路径。

以一个典型的电商下单请求为例：

API 网关 (120ms)
├── 订单服务 (85ms)
│   ├── 库存检查 (15ms)    ← 并行
│   ├── 价格计算 (22ms)    ← 并行
│   └── 写入数据库 (30ms)   ← 串行，等前两个完成
├── 风控检查 (45ms)        ← 与订单服务并行
└── 发送通知 (8ms)         ← 异步，不在关键路径上

关键路径：API 网关 -> 订单服务 -> 价格计算 -> 写入数据库

关键路径的识别算法：

1. 将 Span 树转化为 DAG（有向无环图），边的权重是 Span 的持续时间
2. 找到从根节点到叶节点的最长路径（即关键路径）
3. 关键路径上的 Span 总延迟决定了端到端延迟
4. 优化建议：只有优化关键路径上的 Span 才能降低端到端延迟，优化非关键路径上的 Span 不会有效果

7.3 自动异常检测

追踪数据还可以驱动自动异常检测，常见的方法包括：

基于延迟基线的异常检测：为每个服务、每个端点建立延迟基线（如 P50、P95、P99），当实时延迟显著偏离基线时触发告警。与基于指标的告警相比，基于 Trace 的异常检测可以精确到具体的调用链路。

错误率突增检测：监控每条边（服务间调用）的错误率，当某条边的错误率突增时，结合 Trace 数据定位根因。

拓扑变更检测：当服务依赖图出现新的边（新的服务调用关系）或消失的边时，可能意味着配置变更或故障。自动检测拓扑变更并通知相关团队。

def detect_latency_anomaly(
    service: str,
    operation: str,
    current_p99_ms: float,
    baseline_p99_ms: float,
    threshold_multiplier: float = 3.0
) -> bool:
    """检测延迟异常：当前 P99 超过基线的 N 倍时触发"""
    if baseline_p99_ms <= 0:
        return False
    ratio = current_p99_ms / baseline_p99_ms
    return ratio > threshold_multiplier

7.4 从追踪数据生成 RED 指标

RED 指标（Rate、Error、Duration）是微服务监控的黄金信号。传统做法是在每个服务中用指标 SDK（如 Prometheus Client）手动埋点。但如果已经有了 100% 采样的 Trace 数据，可以从中自动聚合出 RED 指标，省去重复埋点的工作。

Tempo 的 “Metrics Generator” 组件和 Jaeger 的 “SPM”（Service Performance Monitoring）模块都支持这个能力：

Trace 数据（100% 采样）
    |
    v
指标聚合引擎
    |
    ├── Rate: 每秒请求数（按服务、端点分组）
    ├── Error: 错误请求比例
    └── Duration: 延迟分布（P50、P95、P99）
    |
    v
Prometheus / Mimir（存储指标）
    |
    v
Grafana（可视化）

这种”从追踪生成指标”的方法有一个重要前提：追踪数据必须是 100% 采样的，否则生成的指标会有采样偏差。这也是支持 100% 采样的一个重要论点。

八、追踪、指标与日志的关联

8.1 三大可观测信号的关系

可观测性（Observability）由三大信号组成：指标（Metrics）、日志（Logs）和追踪（Traces）。它们不是独立的，而是互相关联的：

• 指标发现问题：告警”支付成功率下降”
• 追踪定位链路：从指标下钻到具体的异常 Trace，看到是银行通道超时
• 日志确认细节：从 Trace 关联到对应的日志，看到具体的错误信息 “connection pool exhausted, max_size=50, active=50”

三者的关联桥梁是 Trace ID。当日志中包含 Trace ID 字段时，可以从任意一个信号跳转到另外两个。

8.2 日志中注入 Trace ID

在日志框架中注入 Trace ID 的方法因语言而异：

Java（Logback + SLF4J + MDC）：

<!-- logback.xml -->
<configuration>
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger - trace_id=%X{trace_id} span_id=%X{span_id} - %msg%n</pattern>
        </encoder>
    </appender>
</configuration>

OpenTelemetry Java Agent 自动将 Trace ID 和 Span ID 注入 MDC（Mapped Diagnostic Context），无需额外配置。

Go（zerolog 示例）：

import (
    "github.com/rs/zerolog/log"
    "go.opentelemetry.io/otel/trace"
)

func handleRequest(ctx context.Context) {
    spanCtx := trace.SpanFromContext(ctx).SpanContext()
    logger := log.With().
        Str("trace_id", spanCtx.TraceID().String()).
        Str("span_id", spanCtx.SpanID().String()).
        Logger()

    logger.Info().Msg("processing payment request")
}

Python（structlog 示例）：

import structlog
from opentelemetry import trace

def get_trace_context_processor(logger, method_name, event_dict):
    span = trace.get_current_span()
    ctx = span.get_span_context()
    if ctx.is_valid:
        event_dict["trace_id"] = format(ctx.trace_id, "032x")
        event_dict["span_id"] = format(ctx.span_id, "016x")
    return event_dict

structlog.configure(
    processors=[
        get_trace_context_processor,
        structlog.dev.ConsoleRenderer(),
    ]
)

8.3 Exemplar：指标到追踪的桥梁

Exemplar（范例）是 Prometheus 2.26 引入的特性，允许在指标数据点上附加一个 Trace ID。当你在 Grafana 中看到一个延迟突增的指标数据点时，可以直接点击跳转到对应的 Trace。

# Prometheus 指标带 Exemplar
http_request_duration_seconds_bucket{le="0.5"} 1000 # {trace_id="4bf92f3577b34da6"}
http_request_duration_seconds_bucket{le="1.0"} 1050 # {trace_id="a1b2c3d4e5f60718"}

OpenTelemetry SDK 自动为指标添加 Exemplar，前提是同时启用了追踪和指标功能。

九、工程案例：Uber 的 OpenTelemetry 迁移

9.1 背景

Uber 是 Jaeger 的创造者，也是分布式追踪领域最有发言权的工程组织之一。Uber 的微服务架构包含数千个服务，每秒产生数十亿个 Span。2021 年，Uber 启动了从自研追踪 SDK 到 OpenTelemetry 的迁移，这是整个行业最大规模的 OTel 迁移项目之一。

9.2 迁移动机

Uber 迁移到 OpenTelemetry 的核心动机：

1. 维护成本：自研 SDK 需要为每种语言（Go、Java、Python、Node.js）单独维护，每种语言的追踪、指标、日志 SDK 各一套，总共十几个代码库。OpenTelemetry 提供统一的多语言 SDK，大幅减少维护负担。

2. 生态兼容性：越来越多的开源库和云服务原生支持 OpenTelemetry，用自研 SDK 意味着无法享受生态红利——比如 gRPC 库的 OTel 中间件、数据库驱动的自动埋点。

3. 人才招聘：新入职的工程师熟悉 OpenTelemetry，不熟悉 Uber 的自研 SDK。使用行业标准降低了入职门槛。

9.3 迁移策略

Uber 的迁移不是一步到位的大爆炸式迁移，而是采用了渐进式策略：

第一阶段：桥接层。在自研 SDK 和 OpenTelemetry API 之间建立桥接层（Bridge），让新代码可以用 OTel API 写埋点，底层仍然走自研 SDK 的数据管道。这样做的好处是新代码从第一天就用标准 API，迁移风险最低。

第二阶段：双写。SDK 同时向自研管道和 OTel Collector 发送数据，在两套系统中对比数据一致性。这个阶段发现了大量的语义差异——比如自研 SDK 和 OTel SDK 对”错误”的定义不同，导致错误率指标偏差。

第三阶段：切换。确认数据一致后，逐服务将数据管道从自研切换到 OTel Collector。切换过程中使用特性开关（Feature Flag）控制，遇到问题可以秒级回滚。

第四阶段：清理。删除自研 SDK 代码，统一使用 OpenTelemetry。

9.4 关键挑战与经验

采样率的调整：Uber 原来使用自适应采样，每个端点每秒保留约 2 条 Trace。迁移到 OTel 后，他们在 Collector 层实现了等效的尾部采样策略，保证迁移前后的数据量一致。

上下文传播的兼容性：迁移期间，部分服务用自研格式（uber-trace-id），部分服务已迁移到 W3C Trace Context。OTel Collector 配置了多格式 Propagator，同时解析两种格式，确保跨服务的 Trace 不会断裂。

性能影响：OTel SDK 的 CPU 和内存开销比自研 SDK 略高（约 5-10%），但在 Collector 层的批量处理优化后，端到端的资源消耗基本持平。

9.5 迁移成果

迁移完成后，Uber 实现了：

• SDK 代码库从 12 个减少到 4 个（每种语言一个 OTel SDK）
• 新框架的自动埋点覆盖率从 60% 提升到 95%（得益于 OTel 社区的 Instrumentation 库）
• 第三方 SaaS 集成（Datadog、Honeycomb 等）从需要自定义适配变为开箱即用
• 追踪数据与指标、日志的关联从手动变为自动（通过 OTel 的 Resource 和 Context 机制）

这个案例说明了一个重要的行业趋势：OpenTelemetry 正在成为可观测性的事实标准，即使是最早自研追踪系统的公司也在向它迁移。

十、追踪管道的全链路架构

10.1 生产环境的完整管道

把前面讨论的所有组件串起来，一个生产级追踪管道的完整架构如下：

flowchart TB
    subgraph 应用层
        A1[服务 A<br/>OTel SDK] -->|OTLP/gRPC| C1
        A2[服务 B<br/>OTel SDK] -->|OTLP/gRPC| C1
        A3[服务 C<br/>OTel SDK] -->|OTLP/gRPC| C2
        A4[服务 D<br/>OTel SDK] -->|OTLP/gRPC| C2
    end

    subgraph 采集层-DaemonSet
        C1[Collector<br/>Node 1] -->|OTLP| LB
        C2[Collector<br/>Node 2] -->|OTLP| LB
    end

    subgraph 采集层-Gateway
        LB[负载均衡<br/>Trace ID 哈希] --> G1[Gateway Collector 1<br/>尾部采样]
        LB --> G2[Gateway Collector 2<br/>尾部采样]
    end

    subgraph 存储层
        G1 --> T[Grafana Tempo]
        G2 --> T
        T --> S3[(S3 对象存储)]
    end

    subgraph 分析层
        T --> GF[Grafana<br/>可视化]
        T --> MG[Metrics Generator<br/>RED 指标]
        MG --> PM[Prometheus/Mimir]
        PM --> GF
    end

10.2 高可用设计

追踪管道的高可用需要关注以下几点：

SDK 层的容错：当 Collector 不可用时，SDK 应该优雅降级——丢弃 Span 而不是阻塞业务请求。OTel SDK 默认使用异步 Span Processor，Span 先写入内存队列，后台线程批量发送。队列满时丢弃最旧的 Span。

Collector 层的容错：DaemonSet Collector 是无状态的，节点故障时该节点上的应用短暂丢失 Span，但不会影响其他节点。Gateway Collector 需要考虑一致性哈希的重新平衡——节点加入或退出时，部分 Trace 的 Span 会被路由到不同实例，导致尾部采样决策不准确。解决方案是使用虚拟节点（Virtual Node）减少重平衡影响。

存储层的容错：Tempo 依赖对象存储的高可用性（S3 的 SLA 是 99.99%）。Ingester 的 WAL 提供了写入缓冲，对象存储短暂不可用时数据不会丢失。

10.3 数据安全与合规

追踪数据可能包含敏感信息——用户 ID、请求参数、数据库查询语句。在金融、医疗等行业，这些数据受到严格的合规要求。

脱敏处理：在 Collector 的 Processor 层配置属性过滤，删除或哈希敏感字段：

processors:
  attributes:
    actions:
      - key: db.statement
        action: delete
      - key: http.request.header.authorization
        action: delete
      - key: user.email
        action: hash

数据保留策略：配置自动清理过期数据。Tempo 支持按租户配置不同的保留周期。

访问控制：Tempo 和 Jaeger 都支持多租户隔离，不同团队只能查看自己服务的 Trace。

十一、常见问题与最佳实践

11.1 Span 命名规范

Span 名称应该是低基数（Low Cardinality）的——不应包含请求 ID、用户 ID 等可变值。

正确: GET /api/users/{id}
错误: GET /api/users/12345

正确: SELECT orders
错误: SELECT * FROM orders WHERE user_id = 'u_789' AND status = 'pending'

高基数的 Span 名称会导致追踪后端的索引膨胀和聚合失效。可变值应该放在 Span Attributes 中。

11.2 控制 Span 数量

过度埋点会导致 Span 爆炸。一条 Trace 包含上千个 Span 时，UI 渲染缓慢，存储成本飙升。几条原则：

• 不要为每次循环迭代创建 Span
• 不要为纯内存计算（如 JSON 序列化）创建 Span
• 对于批量操作（如批量插入 100 条记录），创建一个 Span 并在 Attributes 中记录 batch.size=100，而不是创建 100 个 Span
• 对于缓存命中的查询，考虑用 Span Event 而不是子 Span 记录

11.3 异步链路的追踪

消息队列驱动的异步链路需要特殊处理：

同步链路:
  Span A (client) --CHILD_OF--> Span B (server)

异步链路:
  Span A (producer) --FOLLOWS_FROM--> Span B (consumer)
  或使用 Span Link:
  Span B.addLink(Span A.context)

Kafka 消费者的埋点示例：

func consumeMessage(ctx context.Context, msg *kafka.Message) {
    // 从 Kafka 消息头中提取追踪上下文
    carrier := kafkaHeaderCarrier(msg.Headers)
    parentCtx := otel.GetTextMapPropagator().Extract(ctx, carrier)

    // 创建消费者 Span，使用 Link 而非 CHILD_OF 关联生产者
    tracer := otel.Tracer("order-consumer")
    ctx, span := tracer.Start(parentCtx, "process-order-event",
        trace.WithSpanKind(trace.SpanKindConsumer),
        trace.WithAttributes(
            attribute.String("messaging.system", "kafka"),
            attribute.String("messaging.destination", msg.Topic),
        ),
    )
    defer span.End()

    // 处理消息...
    processOrder(ctx, msg.Value)
}

11.4 追踪的性能开销

OpenTelemetry SDK 的运行时开销通常在以下范围：

这些开销在绝大多数场景下是可接受的。但在超低延迟场景（如高频交易系统，要求 < 100 微秒的延迟），追踪的开销可能不可忽视，需要仔细评估。

11.5 Trace ID 的生成

W3C Trace Context 要求 Trace ID 是 128 位的随机数。OpenTelemetry SDK 默认使用密码学安全的随机数生成器（CSPRNG）。在高 QPS 场景下，CSPRNG 可能成为性能瓶颈。一些优化方案：

• 使用非阻塞的随机数源（如 Linux 的 getrandom 系统调用）
• 预生成一批随机数缓存在内存中
• 在 Trace ID 中嵌入时间戳前缀，既保持唯一性又便于按时间范围查询

十二、落地路线图

对于尚未接入分布式追踪的团队，推荐以下渐进式路线：

第一阶段（1-2 周）：最小可用

1. 部署 OTel Collector（DaemonSet 模式）
2. 部署 Jaeger All-in-One 或 Tempo + Grafana 作为后端
3. 选择一个核心服务，用自动埋点接入
4. 验证 Trace 在 UI 中可见

第二阶段（2-4 周）：覆盖关键链路

1. 将所有核心服务接入自动埋点
2. 为关键业务逻辑添加手动埋点
3. 在日志中注入 Trace ID
4. 配置头部采样（初始采样率 10%）

第三阶段（1-2 月）：生产化

1. 部署 Gateway Collector，配置尾部采样
2. 将存储后端从 All-in-One 迁移到生产级部署（Tempo + S3 或 Jaeger + Elasticsearch）
3. 配置 Exemplar，实现指标到追踪的跳转
4. 建立 Span 命名规范和埋点指南

第四阶段（持续）：深度应用

1. 基于追踪数据构建服务依赖图
2. 实现关键路径分析，指导性能优化
3. 从 Trace 数据生成 RED 指标
4. 评估提高采样率或全量采样的可行性

参考资料

1. Sigelman, B. H., et al. “Dapper, a Large-Scale Distributed Systems Tracing Infrastructure.” Google Technical Report, 2010.
2. W3C Trace Context Specification. https://www.w3.org/TR/trace-context/
3. OpenTelemetry Documentation. https://opentelemetry.io/docs/
4. Jaeger Documentation. https://www.jaegertracing.io/docs/
5. Grafana Tempo Documentation. https://grafana.com/docs/tempo/latest/
6. Shkuro, Y. “Mastering Distributed Tracing.” Packt Publishing, 2019.
7. Uber Engineering Blog. “Distributed Tracing at Uber Scale.” 2021.
8. Sridharan, C. “Distributed Systems Observability.” O’Reilly Media, 2018.
9. OpenTelemetry Collector Configuration. https://opentelemetry.io/docs/collector/configuration/
10. Grafana Labs Blog. “Intro to Metrics-generator: scalable RED metrics from traces in Grafana Tempo.” 2022.
11. Parker, D. “Tail-based Sampling in OpenTelemetry Collector.” OpenTelemetry Blog, 2023.
12. Beyer, B., et al. “Site Reliability Engineering.” O’Reilly Media, 2016.

上一篇：指标体系架构 | 下一篇：告警策略设计