Prometheus 用了几年，这些坑你注意过没？

坑1：标签基数爆炸

最危险的错误：给指标加上高基数标签，比如用户 ID、请求 ID。

一个例子：某指标加了用户 ID 标签，潜在时间序列达到 1200 亿条，活跃序列 5000 万条，内存消耗 150-250GB，Prometheus 直接崩溃。

规则：任何标签的唯一值必须控制在 100 以内。加标签前问三个问题：

初始配置了 97 条告警规则，每天产生 200-300 条告警，团队逐渐麻木。真正的 P0 故障发生时，淹没在噪音里。

解法：只保留 5 条核心告警，标准是：

结果：后续一年只有 3 次真正的值班告警，而之前是 47 次。

平均响应时间正常，但 VIP 用户严重超时——因为他们被正常用户的数据稀释了。

解法：监控 P95、P99，而不只是平均值。按用户类型、地区等维度分别监控。

一次 2 小时的故障排查，如果在 Grafana 上有部署标注，5 分钟就能定位。

解法：所有 CI/CD 变更自动在 Grafana 创建 Annotation，让时间线上的变更一目了然。

存储一年数据每月花费 4200 元，但 99.8% 的查询只访问最近 7 天的数据。

解法：分层存储

复杂看板查询耗时 8-15 秒，严重影响使用体验。

解法：使用 Recording Rules 预计算高频聚合查询。

groups:
  - name: precomputed
    rules:
      - record: job:http_requests:rate5m
        expr: sum(rate(http_requests_total[5m])) by (job)

查询时间从 12 秒降到 200ms。

主 Prometheus 宕机 5 分钟，所有告警失效，恰好在一次重大故障期间。

解法：部署双 Prometheus 实例，配置相同，通过 Alertmanager 去重。