4. 统一数据采集层
统一数据采集层是可观测性平台的“神经末梢”，负责从所有服务、基础设施和中间件中获取遥测数据。本章聚焦于如何通过 OpenTelemetry 实现协议标准化，并围绕 Agent 管理、管道设计和采样策略构建一个高效、可控的采集体系。
4.1 OpenTelemetry 协议与数据模型
OpenTelemetry（OTel）已成为云原生可观测性的事实标准。它定义了三种核心信号的数据模型和传输协议（OTLP），确保不同语言、不同厂商的 SDK 能够产出统一格式的数据。
| 信号类型 | 数据模型核心字段 | OTLP 传输方式 | 典型用途 |
|---|---|---|---|
| Traces | SpanId, TraceId, ParentSpanId, SpanKind, Status, Attributes, Events | gRPC / HTTP (protobuf) | 分布式请求追踪 |
| Metrics | Name, Description, Unit, DataPoints (Gauge/Sum/Histogram), Attributes | gRPC / HTTP (protobuf) | 系统与业务指标 |
| Logs | Timestamp, SeverityText, Body, Attributes, TraceId, SpanId | gRPC / HTTP (protobuf) | 结构化日志 |
关键设计原则： 统一数据模型意味着采集层不再需要为每种信号维护不同的解析器。所有 Agent 和 Collector 只需理解 OTLP 协议，即可实现“一次采集，多后端消费”。
4.2 Agent 管理：从部署到生命周期
Agent 是部署在每台主机或每个 Pod 中的轻量级采集进程。在自助服务视角下，Agent 管理需要解决三个核心问题：如何部署、如何配置、如何升级。
4.2.1 Agent 部署模式对比
| 部署模式 | 适用场景 | 资源开销 | 管理复杂度 |
|---|---|---|---|
| DaemonSet (K8s) | Kubernetes 集群节点 | 低（每节点 1 个） | 低（K8s 原生管理） |
| Sidecar | 需要细粒度隔离的应用 | 中（每 Pod 1 个） | 中（需注入配置） |
| 独立进程 | 虚拟机 / 裸金属 | 低（每主机 1 个） | 高（需配置管理工具） |
| 无 Agent (eBPF) | 内核级网络与性能监控 | 极低（内核态） | 高（需内核版本支持） |
4.2.2 Agent 配置热更新与版本管理
- 配置中心化： 通过统一的配置管理服务（如 etcd / Consul）下发 Agent 配置，避免手动修改每台机器的配置文件。
- 热加载机制： Agent 应支持监听配置变更信号（SIGHUP 或 gRPC Watch），在不重启进程的情况下更新采集规则、目标端点或采样率。
- 灰度升级： 利用 K8s 滚动更新或蓝绿部署策略，逐步替换 Agent 版本，并监控升级后的数据上报成功率与错误率。
常见陷阱： Agent 版本与 Collector 版本不兼容导致 OTLP 数据解析失败。建议在 CI/CD 中增加 OTLP 协议兼容性测试，确保 Agent 升级不会破坏数据管道。
4.3 数据采集管道设计
数据采集管道是 Agent 内部的数据处理流水线。一个典型的管道包含 接收器（Receiver） → 处理器（Processor） → 导出器（Exporter） 三个阶段。OpenTelemetry Collector 是这一设计的标准参考实现。
4.3.1 管道关键处理器
- Batch Processor： 将多个数据点合并为一个批次，减少网络 I/O 次数。建议配置
timeout=5s和send_batch_size=10000。 - Memory Limiter Processor： 防止 Agent 内存溢出。当内存使用超过阈值时，主动丢弃低优先级数据。
- Attributes Processor： 对数据标签进行增、删、改操作，例如统一添加
environment、region等基础设施标签。
4.4 采样策略：在成本与精度之间平衡
采样是控制数据采集成本的核心手段。没有采样策略，高流量服务每天可能产生 TB 级数据，导致存储和计算成本失控。采样策略分为 头部采样 和 尾部采样 两大类。
4.4.1 采样策略对比
| 策略类型 | 决策时机 | 是否保留完整 Trace | 典型算法 | 适用场景 |
|---|---|---|---|---|
| 头部采样 | 请求入口处 | 是（整个 Trace 一致决策） | 概率采样、速率限制 | 高流量服务、全量监控 |
| 尾部采样 | Span 到达 Collector 后 | 是（根据完整 Trace 特征决策） | 错误采样、慢请求采样 | 问题排查、SLO 分析 |
| 概率采样 | 头部 / 尾部均可 | 是 | 固定比例（如 10%） | 通用场景 |
| 自适应采样 | 头部 / 尾部均可 | 是 | 根据流量动态调整比例 | 流量波动大的服务 |
4.4.2 尾部采样策略详解
尾部采样在 Collector 端执行，能够基于完整的 Trace 信息做出更智能的决策。OpenTelemetry Collector 的 tailsampling 处理器支持多种策略组合：
processors:
tailsampling:
decision_wait: 30s # 等待所有 Span 到达的最大时间
num_traces: 50000 # 内存中同时处理的 Trace 数量
expected_new_traces_per_sec: 1000
policies:
- name: error-sampling
type: status_code
status_code: { status_codes: [ERROR] }
sampling_percentage: 100 # 错误 Trace 全量采集
- name: slow-sampling
type: latency
latency: { threshold_ms: 5000 }
sampling_percentage: 50 # 慢请求采样 50%
- name: probabilistic-sampling
type: probabilistic
probabilistic: { sampling_percentage: 10 } # 兜底概率采样 10%
最佳实践： 采用“分层采样”策略——错误 Trace 全量保留，慢请求高比例采样，正常请求低比例概率采样。这样既能保证问题排查的完整性，又能将总体数据量控制在存储预算的 20% 以内。
4.5 统一采集层的自助服务能力
在自助服务视角下，平台需要向用户暴露以下能力：
- 自助接入： 用户通过平台 UI 选择服务语言和部署环境，自动生成 Agent 安装命令和最小配置。
- 采样策略配置： 用户可以为自己的服务设置采样比例和策略，无需全局变更。
- Agent 健康看板： 实时展示 Agent 在线状态、数据上报速率、内存/CPU 使用率。
- 数据管道监控： 展示管道各阶段的吞吐量、错误率、延迟，帮助用户快速定位采集链路瓶颈。
通过统一数据采集层的标准化设计与自助服务能力，平台团队可以将采集运维的复杂性封装在底层，让业务团队专注于数据消费与问题分析，真正实现“采集即服务”。