4. 追踪数据采集：Agent/SDK 部署、采样策略
分布式追踪的数据采集是平台工程落地中最贴近业务应用的环节。采集层负责将链路数据从应用程序中提取出来，并按照预设的采样策略进行过滤，最终将有效数据发送至后端存储。本章聚焦于 Agent/SDK 的部署模式与三种核心采样策略的选型与实现。
4.1 Agent 与 SDK 部署模式
在平台工程实践中，追踪数据的采集通常通过两种方式注入到业务进程中：Agent 模式（无侵入）与 SDK 模式（代码侵入）。两种模式各有适用场景，下表从多个维度进行对比：
| 对比维度 | Agent 模式（无侵入） | SDK 模式（代码侵入） |
|---|---|---|
| 接入方式 | 通过 Java Agent、eBPF、Sidecar 等机制自动注入 | 在代码中显式引入 SDK 并调用 API |
| 业务代码改动 | 零改动 | 需要修改源码，增加埋点 |
| 控制粒度 | 粗粒度，通常按类/方法/接口级别自动拦截 | 细粒度，可精确控制每个 Span 的创建与属性 |
| 部署复杂度 | 需在启动参数或容器编排中挂载 Agent | 需在构建流程中引入 SDK 依赖 |
| 典型场景 | 遗留系统、第三方中间件、快速接入 | 核心业务链路、自定义上下文传递 |
平台工程建议：推荐采用“Agent 兜底 + SDK 增强”的混合策略。对于通用中间件（如 HTTP 客户端、数据库驱动）使用 Agent 自动采集；对于核心业务逻辑，使用 SDK 手动注入业务语义标签，确保关键路径的上下文完整性。
4.2 采样策略：头采样、尾采样、概率采样
在分布式系统中，全量采集所有请求的追踪数据会带来巨大的存储与网络开销。采样策略决定了哪些请求的链路数据被保留。三种主流策略各有优劣，适用于不同的运维与观测目标。
下图展示了三种采样策略在请求生命周期中的决策时机与数据流向：
4.3 头采样（Head-Based Sampling）
头采样在请求进入分布式系统的第一个节点时，根据 TraceId 的哈希值或固定比例决定是否采集整条链路。决策在链路开始前完成，所有后续 Span 继承该决策结果。
- 优点：实现简单，无额外延迟，适合高吞吐场景。
- 缺点：无法针对错误或慢请求进行定向采集，可能丢失高价值链路。
- 典型配置：采样率 1% ~ 10%，通过 TraceId 哈希均匀分布。
// 头采样示例：基于 TraceId 哈希
public boolean shouldSample(String traceId, int sampleRatePercent) {
int hash = traceId.hashCode();
int bucket = Math.abs(hash) % 100;
return bucket < sampleRatePercent;
}4.4 尾采样（Tail-Based Sampling）
尾采样允许所有 Span 数据先被临时缓冲，待请求结束后根据完整链路信息（如是否包含错误、延迟是否超过阈值）决定是否保留。该策略能确保高价值链路被完整采集。
- 优点：精准保留异常与慢请求链路，数据价值密度高。
- 缺点：需要较大的内存缓冲，增加系统复杂度与延迟。
- 典型配置：缓冲窗口 10s ~ 60s，按错误码或 P99 延迟触发保留。
资源注意：尾采样对 Agent 或 Collector 的内存要求较高。在平台工程中，建议为尾采样节点配置独立的内存池，并设置缓冲上限，防止 OOM 影响业务进程。
4.5 概率采样（Probabilistic Sampling）
概率采样在每个 Span 或每个 Trace 的起始节点，以固定的概率独立决定是否采集。与头采样不同，概率采样不依赖 TraceId 的哈希分布，而是使用随机数生成器。
- 优点：实现最为简单，无状态，适合快速接入。
- 缺点：采样结果完全随机，无法保证关键链路的完整性。
- 典型配置：采样率 0.1% ~ 5%，适用于流量极大且对链路完整性要求不高的场景。
// 概率采样示例：基于随机数
public boolean shouldSample(double sampleRate) {
return ThreadLocalRandom.current().nextDouble() < sampleRate;
}4.6 采样策略选型对比
下表从多个关键维度对三种策略进行横向对比，帮助平台工程团队根据业务场景做出选择：
| 维度 | 头采样 | 尾采样 | 概率采样 |
|---|---|---|---|
| 决策时机 | 请求入口 | 请求结束 | 任意节点 |
| 内存开销 | 低 | 高（需缓冲） | 低 |
| 错误链路保留 | 随机保留 | 精准保留 | 随机保留 |
| 慢请求保留 | 随机保留 | 精准保留 | 随机保留 |
| 实现复杂度 | 低 | 高 | 最低 |
| 适用流量 | 高吞吐 | 中低吞吐 | 极高吞吐 |
| 典型采样率 | 1% ~ 10% | 动态（按规则） | 0.1% ~ 5% |
4.7 平台工程中的混合采样策略
在实际落地中，单一采样策略往往无法满足所有需求。平台工程团队通常采用分层混合采样架构：
- 第一层：概率采样（网关层） — 在入口网关处对所有请求进行低比例概率采样（如 1%），用于全局流量观测与容量规划。
- 第二层：头采样（服务层） — 对核心服务设置独立的头采样率（如 10%），确保核心链路的可观测性。
- 第三层：尾采样（Collector 层） — 在 Collector 端对所有 Span 进行尾采样，根据错误码、延迟阈值、自定义标签等规则保留高价值链路。
最佳实践：在平台工程中，建议将采样策略配置为动态可调，通过配置中心（如 Apollo、Nacos）实时下发采样率，无需重启服务。同时，为每个服务设置采样率上限，防止突发流量导致后端存储过载。
通过合理的 Agent/SDK 部署与采样策略组合，平台工程团队可以在数据完整性与资源成本之间取得平衡，为值班台提供高质量、低延迟的分布式追踪数据基础。