4、SLI采集链路全景：采集端（Agent/Exporter）、传输层（协议/队列）、处理层（聚合/降采样）、存储层（时序数据库）
SLI 数据从目标系统到 SLO 自愈引擎，需要经过一条完整的采集链路。链路中任何一个环节的故障或性能瓶颈，都会导致 SLI 数据失真、延迟甚至丢失，进而触发错误的自愈决策。本章从采集端、传输层、处理层、存储层四个维度，拆解 SLI 采集链路的全貌。
4.1 采集端：Agent 与 Exporter
采集端是 SLI 数据的源头，负责从目标系统（应用、中间件、基础设施）中提取原始指标。根据采集模式的不同，主要分为 Agent 模式和 Exporter 模式。
| 对比维度 | Agent 模式 | Exporter 模式 |
|---|---|---|
| 部署方式 | 作为独立进程或 Sidecar 部署在目标主机上 | 作为应用内嵌模块或独立进程暴露 HTTP 端点 |
| 数据拉取 | 主动推送（Push）到采集网关或后端 | 被动拉取（Pull），由 Prometheus 等系统定期抓取 |
| 典型工具 | Telegraf、Fluentd、Datadog Agent | Prometheus Exporter（node_exporter、redis_exporter） |
| 适用场景 | 动态环境、短生命周期任务、需要认证的指标 | 稳态服务、标准协议暴露、大规模集群 |
| SLI 风险 | Agent 崩溃导致数据断流，需配置本地缓冲 | Exporter 响应超时导致抓取失败，需设置超时重试 |
SRE 实践建议： 对于核心 SLI（如请求延迟、错误率），建议采用 Agent + Exporter 双通道采集。Agent 负责高可靠推送，Exporter 提供标准化拉取接口，两者互为备份，避免单点采集失效。
4.2 传输层：协议与队列
传输层负责将采集端的数据安全、可靠、低延迟地送达处理层。协议选择决定了传输效率与兼容性，队列机制决定了抗压能力与数据完整性。
4.2.1 传输协议对比
| 协议 | 传输方式 | 压缩 | 可靠性 | 典型场景 |
|---|---|---|---|---|
| HTTP/HTTPS | 请求-响应 | gzip | 应用层 ACK | Exporter 拉取、Agent 推送 |
| gRPC | 双向流 | Snappy | 流控 + 重试 | 高吞吐、低延迟采集 |
| Kafka | 发布-订阅 | LZ4/Zstd | 持久化 + 副本 | 大规模解耦、异步缓冲 |
| UDP | 无连接 | 无 | 无确认 | 内部网络、可容忍丢包 |
4.2.2 队列缓冲策略
传输层必须引入队列来应对采集峰值和下游抖动。常见的队列策略包括：
- 内存队列： 低延迟，但进程重启会丢失数据。适用于可容忍少量丢包的 SLI。
- 磁盘缓冲队列： 基于 WAL（Write-Ahead Log）或 LevelDB，重启后恢复。适用于关键 SLI。
- 外部消息队列（Kafka/RabbitMQ）： 完全解耦，支持多消费者。适用于跨团队、跨数据中心的 SLI 汇聚。
常见陷阱： 内存队列无限制增长会导致 OOM。必须设置最大队列长度和背压（Backpressure）机制。当队列满时，优先丢弃低优先级 SLI，而非全部拒绝。
4.3 处理层：聚合与降采样
处理层是 SLI 链路的“大脑”，负责将原始指标转换为可用于 SLO 计算的聚合数据。核心操作包括聚合（Aggregation）和降采样（Downsampling）。
4.3.1 聚合策略
| 聚合类型 | 计算方式 | SLI 示例 | 窗口 |
|---|---|---|---|
| 时间窗口聚合 | 固定时间窗口内求和/平均 | 每分钟请求总数 | 1m / 5m / 10m |
| 滑动窗口聚合 | 持续移动的时间窗口 | 最近 5 分钟错误率 | 5m / 30m / 1h |
| 分位数聚合 | T-Digest / HDR Histogram | P99 延迟 | 10m / 1h |
| 计数聚合 | Counter 累加 / Gauge 快照 | 在线 Pod 数量 | 实时 |
4.3.2 降采样策略
降采样用于减少存储量和查询延迟，但必须保证 SLI 精度不丢失。常见策略：
- Last 降采样： 保留窗口内最后一个值。适用于变化缓慢的指标（如内存使用率）。
- Avg 降采样： 保留窗口内平均值。适用于平稳指标（如 CPU 负载）。
- Min/Max 降采样： 保留窗口内极值。适用于告警检测（如最大延迟）。
- Count 降采样： 保留窗口内数据点数。适用于判断数据完整性。
SLO 自愈关键： 降采样粒度必须与 SLO 窗口对齐。例如，SLO 窗口为 5 分钟，降采样粒度应 ≤ 1 分钟，否则自愈剧本无法感知窗口内的突发错误。
4.4 存储层：时序数据库
存储层是 SLI 数据的最终归宿，决定了查询性能、数据保留策略和自愈剧本的实时性。主流时序数据库（TSDB）包括 Prometheus、VictoriaMetrics、TimescaleDB、InfluxDB。
4.4.1 存储层关键特性对比
| 特性 | Prometheus | VictoriaMetrics | TimescaleDB | InfluxDB |
|---|---|---|---|---|
| 存储引擎 | TSDB（自研） | LSM-Tree + 列式 | PostgreSQL 分区 | TSM（自研） |
| 压缩比 | 1:5 ~ 1:10 | 1:10 ~ 1:20 | 1:3 ~ 1:5 | 1:5 ~ 1:15 |
| 查询延迟 | 低（内存索引） | 极低（倒排索引） | 中（SQL 优化） | 低（内存缓存） |
| 高可用 | Thanos / Cortex | 内置集群 | PG 流复制 | 企业版 |
| SLI 场景 | 原生 PromQL，适合实时告警 | 兼容 PromQL，适合大规模 | 复杂 SQL 分析，适合历史趋势 | Flux 查询，适合 IoT |
4.4.2 数据保留与降采样联动
存储层必须与处理层的降采样策略联动，形成分层存储：
- 热数据（最近 7 天）： 原始粒度（10s ~ 1m），用于实时自愈剧本。
- 温数据（7 ~ 30 天）： 1m 降采样，用于短期趋势分析。
- 冷数据（30 天以上）： 10m ~ 1h 降采样，用于月度 SLO 报告。
存储成本优化： 对于非核心 SLI，可以设置更短的保留期（如 3 天）或更高的降采样粒度（如 1h）。核心 SLI 必须保留原始粒度至少 7 天，以支持自愈剧本的精确回放。
4.5 采集链路全景图
下图展示了 SLI 从采集端到存储层的完整链路，以及各层之间的数据流和关键组件。
4.6 链路优化要点总结
基于全景图，SRE 团队在优化 SLI 采集链路时应重点关注以下要点：
- 采集端冗余： 核心 SLI 使用 Agent + Exporter 双通道，避免单点故障。
- 传输层缓冲： 引入 Kafka 或磁盘队列，应对采集峰值和下游抖动。
- 处理层精度： 降采样粒度必须 ≤ SLO 窗口的 1/5，确保自愈剧本感知突发。
- 存储层分层： 热/温/冷分层存储，平衡查询性能与存储成本。
- 全链路监控： 每层都暴露关键指标（延迟、吞吐、错误率），形成采集链路的可观测性。
SRE 自愈黄金法则： 采集链路的可靠性必须高于被监控系统的可靠性。如果采集链路本身不可靠，SLO 自愈剧本将基于错误数据做出错误决策，导致“误自愈”或“漏自愈”。建议为采集链路设置独立的 SLO（如采集成功率 ≥ 99.9%，端到端延迟 ≤ 30s）。