4. SLI 指标采集方法：基于日志、基于指标、基于追踪、基于探针的 SLI 采集

SLI 的原始数据必须通过可靠的采集通道获取。不同的数据源决定了采集方式、精度和成本。本章将系统讲解四种主流的 SLI 采集方法：基于日志、基于指标、基于追踪和基于探针。理解每种方法的适用场景与局限性，是设计高质量 SLO 的基础。

4.1 四种采集方法概览

下表从数据源、典型工具、采集延迟、适用 SLI 类型四个维度进行横向对比，帮助你快速建立全局认知。

4.2 基于日志的 SLI 采集

日志是最原始、最丰富的可观测性数据源。通过结构化日志（如 JSON 格式）可以提取出每次请求的 status_code、latency_ms、error_type 等字段，进而聚合为 SLI。

4.2.1 采集流程

1. 日志产生： 应用在关键路径输出结构化日志，包含请求 ID、耗时、状态码。
2. 日志采集： Filebeat / Fluentd 等 Agent 将日志发送到中心存储。
3. 日志解析： 使用 Logstash / Loki 的查询语言提取字段。
4. 指标聚合： 对解析后的字段做计数、分位数计算，生成 SLI 时序数据。

4.2.2 典型 SLI 计算示例

假设日志格式为 JSON，每行包含 status 和 duration 字段。以下 LogQL 查询计算过去 5 分钟的错误率 SLI：

sum(rate({app="my-service"} | json | status >= 500 [5m]))
/
sum(rate({app="my-service"} | json [5m]))

4.3 基于指标的 SLI 采集

指标采集是目前最主流的 SLI 数据源。应用通过暴露 Prometheus 格式的 /metrics 端点，或通过 StatsD / Telegraf 推送指标，再由时序数据库存储和查询。

4.3.1 指标类型与 SLI 映射

4.3.2 采集架构要点

• 拉模式 vs 推模式： Prometheus 采用拉模式，适合动态服务发现；推模式（如 Graphite）适合短生命周期任务。
• 指标基数控制： 避免高基数标签（如 user_id、request_id）导致存储爆炸。SLI 指标应使用低基数标签（如 service、endpoint、status_class）。
• 采集频率： 通常 15～30s 一次。对于高精度 SLO（如 99.99%），建议缩短至 10s 并配合预聚合。

4.4 基于追踪的 SLI 采集

分布式追踪能够还原一次请求经过的所有服务节点，从而计算端到端延迟和依赖错误率。追踪数据以 Span 为基本单元，多个 Span 组成 Trace。

4.4.1 追踪 SLI 的关键指标

• Trace 完成率： 成功完成所有 Span 的 Trace 占比。
• Span 错误率： 每个服务节点的错误 Span 比例。
• 端到端延迟： 从入口 Span 开始到最后一个 Span 结束的耗时。

4.4.2 采样策略对 SLI 的影响

由于全量追踪成本极高，生产环境通常采用采样策略。不同采样方式对 SLI 精度的影响如下：

4.5 基于探针的 SLI 采集

探针（Probe）通过模拟真实用户请求，从外部主动探测服务可用性和性能。这种方式不依赖应用内部埋点，适合验证用户侧体验。

4.5.1 探针类型

• HTTP 探针： 发送 HTTP GET/POST 请求，检查状态码、响应时间、响应体内容。
• TCP 探针： 检查端口是否可达，用于基础设施可用性 SLI。
• ICMP 探针： Ping 探测，用于网络延迟和丢包率。
• 浏览器脚本探针： 执行完整的用户操作流程（登录、搜索、下单），验证功能正确性。

4.5.2 探针部署位置

探针的部署位置直接影响 SLI 的语义：

4.6 四种采集方法的协同架构

下图展示了一个生产级 SLI 采集系统的典型架构，四种方法各司其职，共同支撑 SLO 监控。

4.7 方法选择决策树

在实际项目中，可以根据以下条件快速选择采集方法：

1. 是否需要验证用户侧体验？ → 是 → 优先使用探针；否 → 进入下一步。
2. 是否已有结构化日志？ → 是 → 使用日志快速提取 SLI；否 → 进入下一步。
3. 是否需要毫秒级精度和低存储成本？ → 是 → 使用指标；否 → 进入下一步。
4. 是否需要跨服务依赖分析？ → 是 → 补充追踪采集。