存储与成本：采样、下采样、冷热分层、对象存储

某中等规模 SaaS 公司（200 服务、5000 Pod、总 QPS 约 50000）的可观测性月账单拆解：Loki $8000（日志索引 + 对象存储）+ Tempo $5000（全部走 S3）+ Mimir $3000（时序存储）+ Grafana Cloud $2000 = 每月 $18000。其中至少 $9000 花在了”过去三个月没人查过的日志”上。

可观测性数据的增长是线性的（与 QPS 和节点数成正比），但存储账单的增长常常是超线性的——因为数据堆积的速度超过了你去清理的速度。降本的杠杆从大到小排列：采样 > 保留期 > 压缩 > 冷热分层 > S3 比 SSD 便宜。本文拆解每个杠杆的工程原理和操作步骤。

一、五大支柱的成本结构

80/20 法则在这里同样成立：通常是 20% 的高基数服务产生了 80% 的可观测数据量。定位这几个”大户”是成本治理的第一步——按服务拆分 Metrics series count、Log volume（GB/day）、Trace span count、Profile data size。

二、采样：成本的最强杠杆

Trace 的 1% 采样 vs 100% 全量——存储成本差 100 倍。但 1% 的采样意味着 99% 的请求完全没有 Trace。采样率的选择没有最优解——只有在你当前的存储预算和排障需求之间找平衡。

按级别分层采样是最有效的策略：

• ERROR 全量：100%。错误请求的 Trace 是排障的核心资产，不值得省。
• 慢请求（> 阈值）全量：100%。同上。
• 正常请求 baseline：1%–10%，取决于预算。
• DEBUG/INFO 日志：1%–10%，ERROR 全量不变。

按服务差异化采样：订单服务的 1% 采样和报表服务的 100% 采样——存储成本接近但排障价值完全不对等。

三、保留期（Retention）的工程策略

各支柱的典型保留期基线：

• Metrics：原始 7–14 天，下采样聚合 30–90 天。用 Recording Rules 做长期聚合。
• Logs：7–30 天。按业务重要性分级——支付链 30 天、管理后台 7 天。
• Traces：3–7 天。Trace 的排障价值集中在前 48 小时——事故发生后 2 天内会查，之后就很少了。
• Profiles：14 天。用于性能趋势对比，但不需要长时间序列。

保留期的”断崖效应”：从 30 天压到 14 天——存储成本减半。从 14 天压到 7 天——再减半。但从 7 天压到 3 天——出事故时发现日志已被删除，根因永远找不到。不要为了省最后一两个月压到不可接受的短。

四、下采样（Downsampling）

时序数据的下采样是最成熟的实践——原始 15s 分辨率保留 7 天 → 5min 分辨率保留 30 天 → 1h 分辨率保留 1 年。Mimir/Thanos 的 compactor 在处理 block 时自动做这一步——将多个小 block 合并为大时间窗口的聚合 block。代价是精度丢失——下采样后你无法查询”30 天前某一秒的精确 CPU 使用率”，只能看到 5 分钟的平均值——但这对于容量规划完全够用。

日志的”下采样”是 pattern 聚合——将原始日志按 pattern 分组（如 Drain 算法），只保留 pattern 模板和出现频率。排障时看”这个服务的 ERROR 模式中，哪种最频繁”——而不是翻原始日志——效率更高。

五、冷热分层

• 热数据（SSD / NVMe）：最近 1–3 天。需要毫秒级查询。
• 温数据（HDD / 高性能对象存储）：3–30 天。秒级查询可接受。
• 冷数据（对象存储归档 / Glacier）：30 天以上。合规/审计需要，分钟到小时级恢复可接受。

Loki 的 boltdb-shipper 架构天生支持这种分层：index 在 SSD 上，chunk 在 S3 上。Tempo 的所有 block 都在 S3 上。Prometheus TSDB 需要显式分层——通过 Thanos/Mimir 的 sidecar → 对象存储上传。

六、降本路径图

1. 分层各支柱的数据量（Prometheus TSDB size、Loki chunk size、Tempo block size per day）
2. 按”过去 30 天有人查过吗”标记冷热
3. 逐步缩短保留期直到团队能接受的底线
4. 开启采样——先采样 INFO 日志和正常 Trace
5. 冷热分层——热数据 SSD → 温数据 HDD → 冷数据 S3
6. 季度 review：数据增长率是否超过业务增长率？（超过 → 有基数泄漏或日志风暴）

七、工程坑点

保留期压太短。3 天保留期 → 出事故时日志已删 → Root Cause 永远找不到。保留期的底线是”长于你的事故响应周期”。

Loki max_entries_limit_per_query 设太大。一次查询扫描数百 TB 对象存储 → 查询执行 30 分钟 + S3 请求费用爆炸。

为了省成本把 sampling_rate: 0.01 写成了 sampling_rate: 0。零采样 = 所有 Trace 全丢。永远在配置变更后验证至少还有 Trace 进存储。

八、关键概念回顾

• 五大降本杠杆排序：采样 > 保留期 > 压缩 > 冷热分层 > S3 vs SSD。
• 保留期底线：长于事故响应周期。支付链 30 天、管理后台 7 天。
• 冷热分层：热（SSD 1-3天）→ 温（HDD 3-30天）→ 冷（S3 Archive 30天+）。
• 季度 review：数据增长率与业务增长率对齐——错位意味着泄漏。

九、下一步

成本控制住之后，下一个问题是多租户——当全公司的可观测性平台共用一个基础设施时，如何保证数据隔离和成本分摊。下一篇 多租户与安全。

上一篇：告警体系：Alertmanager、PagerDuty、OnCall 与分级抑制

下一篇：多租户与安全：数据隔离、标签治理、PII 清洗

参考资料

1. Grafana, Mimir — Compactor, https://grafana.com/docs/mimir/latest/operators-guide/architecture/components/compactor/
2. Grafana Loki, Storage, https://grafana.com/docs/loki/latest/operations/storage/
3. Thanos, Compaction, https://thanos.io/tip/components/compact.md/