数据治理

概述 先说个场景：凌晨三点，你被告警吵醒，爬起来打开 Grafana，发现几十个 Dashboard 里找不到一条有用的信息。指标倒是有几百万条——但全是垃圾。 这不是个例。我见过太多团队，Prometheus 部署完就不管了，指标只增不减，告警规则越写越多，最后监控系统自己先挂了：Prometheus 内存 OOM、查询超时 30 秒、告警评估延迟 5 分钟以上。监控系统成了最大的故障源，这话说出去都讽刺。 监控数据治理解决的就是这个问题。它不是什么高深理论，说白了就一句话：搞清楚你有哪些指标、哪些有用、哪些该删、怎么管它们的一生。 这篇文章从指标生命周期管理的角度，拆解监控数据治理的五个阶段：指标定义、采集策略、存储优化、质量度量、废弃淘汰。每个阶段都配实操代码和踩坑经验。 指标爆炸的根因：不是数据多了，是管不住 指标为什么会膨胀 指标膨胀不是一夜之间发生的。通常的路径是这样的： 初期：Node Exporter + cAdvisor，几百条指标，Prometheus 跑得好好的 业务接入：每个服务埋点，每个中间件装 Exporter，指标涨到几万条 高基数炸弹：有人把 user_id、request_id、session_id 塞进了标签，时序数据量从几万条直接爆炸到百万级 灾难：Prometheus 内存飙升、磁盘写满、查询卡死 这里的核心罪魁祸首是高基数标签。 Prometheus 的时间序列模型是：指标名{标签1="值1", 标签2="值2"} → 数值。每增加一个标签值组合，就多一条时间序列。举个例子： # 低基数：3 条时间序列 http_requests_total{method="GET",status="200"} http_requests_total{method="POST",status="200"} http_requests_total{method="GET",status="404"} # 高基数炸弹：100万用户 = 100万条时间序列 http_requests_total{method="GET",status="200",user_id="12345"} http_requests_total{method="GET",status="200",user_id="12346"} ... 第二行代码看起来人畜无害，但如果 user_id 有 100 万个值，就是 100 万条时间序列。Prometheus 单实例承载上限大约 50 万条 TimeSeries（受内存和磁盘 I/O 约束），直接超限。 高基数标签的常见来源 来源 典型场景 危害程度 替代方案 用户 ID http_requests_total{user_id="..."} 致命 用日志记录，或聚合为百分位 请求 ID http_request_duration{trace_id="....