4. 追踪数据采集：自动埋点与手动埋点策略、Agent 与 SDK 部署模式、采样策略

分布式追踪的数据采集是整个可观测性体系的“第一公里”。采集策略的优劣直接决定了故障排查时能否拿到有效数据，以及存储成本是否可控。本章从埋点方式、部署模式、采样策略三个维度展开，帮助值班台工程师在实战中做出合理选择。

4.1 自动埋点与手动埋点策略

埋点（Instrumentation）是将追踪代码注入应用程序的过程。根据注入方式的不同，分为自动埋点和手动埋点两大类。

4.2 Agent 与 SDK 部署模式

部署模式决定了追踪能力如何交付到目标服务中。主流方案分为 Agent 模式和 SDK 模式，两者在运维复杂度、资源隔离、版本管理上存在显著差异。

4.2.1 Agent 模式

• 原理：以独立进程或 sidecar 形式部署，通过字节码增强或网络代理劫持应用流量。
• 优势：应用无感知，升级 Agent 无需重启业务进程；支持多语言统一管理。
• 劣势：额外资源开销（CPU/内存）；对 Agent 稳定性要求高，故障可能影响宿主。
• 典型实现：Java Agent（如 OpenTelemetry Java Agent）、eBPF 内核级 Agent。

4.2.2 SDK 模式

• 原理：将追踪库以依赖形式引入应用代码，编译时链接。
• 优势：资源开销可控，与应用进程共享生命周期；可精细控制埋点行为。
• 劣势：升级 SDK 需要重新编译部署；多语言版本管理复杂。
• 典型实现：OpenTelemetry SDK、Jaeger Client、Zipkin Brave。

4.3 采样策略

在高吞吐分布式系统中，全量采集所有 Span 会产生海量数据，导致存储成本爆炸和查询性能下降。采样策略是平衡数据完整性与成本的关键手段。

4.3.1 头采样（Head Sampling）

在请求入口处（Trace 起始端）决定是否采样。一旦决定，整个 Trace 的所有 Span 要么全部采集，要么全部丢弃。

• 优点：实现简单，决策点单一，适合固定采样率场景。
• 缺点：无法根据请求执行过程中的特征（如错误、延迟）动态调整；低概率采样时容易丢失异常链路。
• 典型实现：固定概率采样（如 1%）、速率限制采样（每秒 N 条 Trace）。

4.3.2 尾采样（Tail Sampling）

先采集所有 Span 到本地缓冲区，待 Trace 结束后根据完整特征（是否包含错误、延迟是否超阈值、特定标签）决定是否保留。

• 优点：可基于完整 Trace 信息做决策，确保异常链路 100% 保留；支持复杂策略（如错误优先、慢调用优先）。
• 缺点：需要额外缓冲区存储，增加延迟和资源开销；实现复杂度高。
• 典型实现：OpenTelemetry Collector 的 tail_sampling 处理器、Jaeger 的尾部采样策略。

4.3.3 概率采样（Probabilistic Sampling）

基于 Trace ID 的哈希值或随机数，按固定概率决定是否采样。可独立应用于每个 Span，也可用于 Trace 级别。

• 优点：计算开销极低，适合超大规模集群；无状态，易于水平扩展。
• 缺点：无法感知请求内容，可能丢失关键异常链路。
• 典型实现：Trace ID 取模、随机数比较。

4.4 采样策略组合与值班台实战

单一采样策略无法满足所有场景。值班台工程师需要根据业务重要性和故障排查需求，设计多级采样组合策略。

# OpenTelemetry Collector 尾采样配置示例
processors:
  tail_sampling:
    decision_wait: 30s          # 等待 Trace 结束的最长时间
    num_traces: 100000          # 缓冲区最大 Trace 数
    expected_new_traces_per_sec: 1000
    policies:
      - name: error-policy
        type: status_code
        status_code: { status_codes: [ERROR] }
      - name: slow-policy
        type: latency
        latency: { threshold_ms: 5000 }
      - name: probabilistic-policy
        type: probabilistic
        probabilistic: { sampling_percentage: 10 }