3. Collector 架构基础：OpenTelemetry Collector 架构、Pipeline 概念与数据流模型
在分析 Collector 配置对 SLI 口径数据完整性的影响之前，必须深入理解 OpenTelemetry Collector 的底层架构。Collector 并非一个简单的数据转发代理，而是一个基于 Pipeline（管道） 模型的模块化处理引擎。其架构设计直接决定了数据在采集、处理、导出过程中的完整性与一致性。
3.1 整体架构：从 Agent 到 Gateway 的部署模式
OpenTelemetry Collector 支持两种核心部署模式，架构上的差异会影响数据路由策略和故障域：
| 部署模式 | 典型角色 | 数据完整性关注点 |
|---|---|---|
| Agent 模式 | 与应用程序同主机部署（Sidecar 或 DaemonSet） | 本地缓冲、进程级故障隔离、低延迟但需管理大量实例 |
| Gateway 模式 | 独立集群部署，作为集中式数据路由与处理层 | 全局去重、批量处理、下游导出失败重试、数据完整性校验 |
SLI 口径提示： 在 Gateway 模式下，如果 Pipeline 配置了多个 Processor 对数据进行聚合或采样，必须确保 SLI 口径的统计窗口与 Processor 的刷新周期对齐，否则会出现数据重复或遗漏。
3.2 Pipeline 核心概念：Receivers / Processors / Exporters
Pipeline 是 Collector 处理数据的逻辑单元，由三个组件类型串联而成。每个组件都可能是数据完整性的关键节点：
- Receivers（接收器）：数据入口。支持 gRPC、HTTP、Prometheus 拉取、Jaeger、Zipkin 等多种协议。接收器必须配置端点与认证，其超时与重试策略直接影响数据是否被完整接收。
- Processors（处理器）：数据处理中间件。包括过滤、采样、属性修改、批处理、内存限流、Span 去重等。处理器是 SLI 口径数据完整性最容易受损的环节——错误的过滤规则会直接丢弃关键指标。
- Exporters（导出器）：数据出口。将处理后的数据发送到后端存储或分析系统（如 Prometheus、Jaeger、Kafka、OTLP 后端）。导出器的重试、队列、超时配置决定了数据是否最终被持久化。
关键原则： 一个 Pipeline 必须至少包含一个 Receiver 和一个 Exporter。Processor 是可选的，但在生产环境中几乎总是需要至少一个批处理 Processor 来优化吞吐量。
3.3 数据流模型：从接收到导出的完整路径
下图展示了单个 Pipeline 内部的数据流动路径，以及数据完整性检查点：
3.4 多 Pipeline 与数据路由
一个 Collector 实例可以同时运行多个 Pipeline，每个 Pipeline 可以配置不同的 Receivers 和 Exporters。这种设计允许将不同口径的数据（例如 SLI 指标与调试日志）路由到不同的后端，但同时也引入了数据交叉污染的风险：
- Pipeline 隔离性：默认情况下，不同 Pipeline 的数据是隔离的。但如果多个 Pipeline 共享同一个 Receiver 实例，则该 Receiver 的数据会被复制到每个 Pipeline，可能导致重复计数。
- 数据完整性风险：当使用
batchProcessor 时，如果 Pipeline A 和 Pipeline B 的批处理周期不一致，同一批数据可能被拆分成不同大小的批次导出，影响下游 SLI 聚合的准确性。
常见陷阱： 在配置多 Pipeline 时，如果误将同一个 Exporter 同时用于两个 Pipeline，且后端不支持幂等写入，则 SLI 口径数据会出现重复。建议每个 Pipeline 使用独立的 Exporter 实例，或确保后端具有去重能力。
3.5 配置示例：一个典型的 SLI 数据 Pipeline
以下 YAML 配置展示了一个针对 SLI 口径数据完整性的 Pipeline 示例，包含了关键的数据完整性保障参数：
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
# 接收超时：防止连接泄漏导致数据丢失
read_timeout: 10s
write_timeout: 10s
processors:
# 批处理：控制数据导出粒度，避免小批次导致后端压力
batch:
timeout: 5s
send_batch_size: 1024
send_batch_max_size: 2048
# 内存限流：防止 Collector OOM 导致数据全部丢失
memory_limiter:
check_interval: 1s
limit_mib: 512
spike_limit_mib: 128
# 属性修改：确保 SLI 口径标签统一
attributes:
actions:
- key: sli_version
value: "v2.1"
action: upsert
exporters:
otlp:
endpoint: "backend:4317"
tls:
insecure: true
# 重试与队列：保障数据最终一致性
retry_on_failure:
enabled: true
initial_interval: 5s
max_interval: 30s
max_elapsed_time: 300s
sending_queue:
enabled: true
queue_size: 5000
service:
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, batch, attributes]
exporters: [otlp]
SLI 口径数据完整性要点： 上述配置中，
memory_limiter 防止 Collector 进程崩溃导致数据丢失；batch 的 send_batch_max_size 限制单次导出数据量，避免后端写入超时；retry_on_failure 的 max_elapsed_time 定义了数据重试的最大时间窗口，超过后数据将被丢弃——这个值需要根据 SLI 口径的容忍延迟来调整。
3.6 架构对 SLI 数据完整性的影响总结
| 架构组件 | 数据完整性风险 | 推荐配置策略 |
|---|---|---|
| Receiver | 连接超时导致数据未被接收 | 设置合理的 read_timeout 和 write_timeout，启用 gRPC 健康检查 |
| Processor (filter) | 过滤规则误删 SLI 口径数据 | 在测试环境验证过滤逻辑，使用 include 白名单模式而非 exclude |
| Processor (batch) | 批处理窗口导致数据截断或延迟 | 根据 SLI 口径的聚合周期设置 timeout，通常为聚合周期的 1/2 |
| Exporter | 队列溢出或重试耗尽导致数据丢失 | 监控 exporter_queue_size 指标，设置 max_elapsed_time 为 SLI 口径容忍延迟的 2 倍 |
| 多 Pipeline | 数据复制或路由冲突 | 每个 Pipeline 使用独立的 Exporter 实例，避免共享 Receiver 导致数据复制 |