监控数据爆表之后：降采样、预聚合与存储的三本账

指标体系建起来的前三个月，一切都很美好。第六个月，问题来了：查询大盘要转八秒，存储费用翻了四倍，回溯两周前的故障现场发现数据已经被清理了。这是监控系统成长的必经阶段——上一篇聊了该盯哪些指标，这篇聊指标数据本身的治理：三本账，算清楚监控系统的容量。

第一本账：降采样账。

原始 10 秒粒度的数据保留 7 天，5 分钟聚合保留 90 天，1 小时聚合保留两年——这样分层之后，存储开销能降两个数量级。但降采样有个经典陷阱：百分位指标不能用「平均的平均」。把每五分钟的 p99 拿来再取平均，得到的数字和真实的 p99 毫无关系，长尾毛刺会被平均成一马平川。正确做法是在聚合时存分位数摘要（sketch），查询时再合并计算。

第二本账：预聚合账。

大盘查询慢，是因为每次都在扫原始数据现算。把查询热路径预先算好——按服务、按接口维度的 rollup 表提前物化——大盘查询从扫上亿行变成扫几千行，延迟从秒级降到毫秒级。

预聚合的代价是维度组合爆炸：三个服务 × 五个接口 × 四个环境，组合数很快就失控。实践原则是只预聚合高频查询维度（大盘和 TOPN 用到的那些），长尾维度留给原始数据现场查。别追求全预聚合，那是在用存储换一个用不上的周全。

第三本账：存储选型账。

时序数据库和通用数据库在监控场景的差异，本质是压缩比和保留策略的差异：时序库针对时间线连续性做的列式压缩，同样数据体量能省数倍空间；冷数据转对象存储归档，又是一个数量级。如果现有平台是通用数据库扛监控，算一算这两年数据的规模曲线，迁移的 ROI 通常比想象中高。

一个容易被忽略的坑：告警链路别走降采样数据。降采样天然抹掉短毛刺，而短毛刺恰恰是很多故障的信号。核心指标的告警走原始数据流，大盘看趋势走聚合——两条链路分开，别为省一份存储把告警灵敏度搭进去。

监控系统的容量也是容量。业务在长，指标在涨，数据治理不是优化项，是监控体系能不能活过第二年的生存项。三本账早点算，别等账单和查询延迟一起爆表。

（可观测系列：指标选型 → 本文：数据治理 → 下一篇：告警 SLO 与值班升级）