1. 课程导论：为什么需要指标降采样？存储成本失控的典型场景与课程目标
在云原生与微服务架构大规模普及的今天，可观测性数据——尤其是指标（Metrics）——正以指数级速度增长。每增加一个 Pod、每部署一个新服务、每调整一次告警规则，都会产生新的时间序列。当指标基数（Cardinality）与采集频率叠加后，存储成本往往成为 SRE 团队最头疼的预算黑洞。
1.1 存储成本失控的典型场景
以下三个场景在百微/千节点规模的集群中极为常见，每一个都可能导致存储成本在数月内翻倍甚至翻三倍：
| 场景 | 典型表现 | 月存储增量（估算） |
|---|---|---|
| 高基数标签爆炸 | HTTP 请求标签包含 user_id、request_id、session_id 等唯一值 | +2~5 TB |
| 高频采集叠加 | 所有指标统一 10s 采集，即使 99% 的指标变化周期 > 60s | +1~3 TB |
| 无差别保留策略 | 原始精度数据保留 90 天，降采样后数据保留 365 天 | +4~8 TB |
⚠️ 成本失控的连锁反应： 存储成本上升 → 查询性能下降 → 告警延迟 → 被迫增加查询并发 → 进一步推高基础设施费用。最终，可观测性预算可能占到总基础设施成本的 15%~25%。
1.2 为什么需要指标降采样？
指标降采样（Metrics Downsampling）不是简单的“丢弃数据”，而是在精度与成本之间寻找最优平衡点。其核心价值体现在三个层面：
- 存储成本压缩： 将原始高精度数据（如 10s 粒度）聚合为分钟级或小时级数据，存储体积可减少 60%~90%。
- 查询性能提升： 降采样后的数据量更小，聚合查询（如过去 7 天的 P99 延迟）响应时间从秒级降至毫秒级。
- 长期趋势保留： 原始数据保留 7~14 天用于故障排查，降采样数据保留 1~2 年用于容量规划与成本分析。
1.3 OpenTelemetry 在降采样中的角色
OpenTelemetry（OTel）作为可观测性数据采集与处理的标准层，天然具备在数据管道中插入降采样逻辑的能力。通过 OTel Collector 的 Processor 组件，可以在数据进入后端存储之前完成聚合、过滤、标签裁剪等操作，避免“先存后删”的浪费。
1.4 课程目标与学习路径
本课程旨在帮助 SRE、平台工程师与可观测性负责人，系统掌握基于 OpenTelemetry 的指标降采样策略与存储成本控制方法。完成本课程后，你将能够：
- 诊断存储成本瓶颈： 识别高基数指标、无效标签与冗余采集频率。
- 设计降采样策略： 根据指标类型（Counter / Gauge / Histogram）选择聚合函数与窗口大小。
- 配置 OTel Collector： 使用
filter、metricstransform、cumulativetodelta等 Processor 实现降采样管道。 - 验证降采样效果： 通过数据对比与成本报表量化节省成果。
- 建立长期治理机制： 将降采样策略纳入 CI/CD 与成本运营流程。
📊 预期收益： 在典型微服务集群（500+ 服务、10 万+ 时间序列）中，通过本课程的方法可将指标存储成本降低 60%~80%，同时保持 95% 以上的查询场景不受影响。
1.5 谁应该学习本课程？
| 角色 | 核心痛点 | 课程价值 |
|---|---|---|
| SRE / 运维工程师 | Prometheus / Thanos 存储成本持续上涨 | 掌握 OTel 降采样配置，直接降低账单 |
| 平台工程师 | 需要为多团队设计统一的可观测性管道 | 学习可复用的降采样策略与治理模式 |
| 技术管理者 | 可观测性预算失控，需要量化 ROI | 获得成本模型与效果评估方法 |
在接下来的章节中，我们将从降采样的核心原理开始，逐步深入到 OTel Collector 的实战配置、聚合算法选择、标签裁剪策略，以及最终的存储成本核算与自动化治理。每一章都配有可运行的配置示例与验证步骤，确保学完即用。