适用场景

可观测性成本涨得最快的地方通常不是数据量，而是「基数」：一个标签塞进用户 ID，指标数量翻几万倍。治理顺序是：先砍高基数，再谈保留期，最后才考虑换存储。

配置步骤（指标基数治理）

# 基数排查（Prometheus）
# 1) 系列总数
topk(10, count by (__name__)({__name__=~".+"}))

# 2) 单指标基数最高的标签
topk(10, count by (instance)(node_cpu_seconds_total))
topk(5, count by (path)(http_requests_total))

# 3) 高基数元凶示例
#   path="/order/123456"      -> 应为 "/order/:id"
#   user_id="u_88213"        -> 不应作为标签
#   trace_id                 -> 绝不进指标

# 处置
- 采集端做标签规范化（路由模板化）
- 丢弃或聚合掉无界标签
- 在 relabel 配置里 drop 掉敏感/高基数标签

关键参数与建议

  • 成本构成：采集与传输、存储、查询计算、商业 License 四块分开算
  • 基数治理：禁止把 user_id/order_id/URL 全路径等无界值做标签
  • 采样与聚合：明细降采样保留，聚合指标长期保留
  • 保留期分级：核心服务 30 天、边缘服务 7 天、调试数据 3 天
  • 查询优化：看板刷新频率与查询复杂度要受控
  • License 管理：按节点/数据量计费的授权要核对实际使用量
  • 月度报表：按环境/服务/数据源拆成本，找出增长最快的来源
  • 验收：成本环比稳定，且没有因为省钱丢掉关键可观测能力

容易踩的坑

  • 把 URL 全路径当标签，接口参数一变就多一条时间线
  • 把用户 ID、订单号写进标签，基数爆炸
  • 采集端不规范化，同一个接口有多种路径写法
  • 只在 Prometheus 侧删数据，采集端继续造
  • 没有基数监控，等 Prometheus OOM 才发现
  • 治理前不备份配置，误删关键标签无法回退

验证与巡检

# 基数与内存
curl -s localhost:9090/api/v1/status/tsdb | head -c 400
promtool tsdb analyze /var/lib/prometheus 2>/dev/null | head -20

# 目标：单指标基数 < 10 万，总系列数增长平稳
  • 巡检：基数 Top10 受控、relabel 规则存在、Prometheus 内存水位 < 70%

小结

可观测性成本验收：能说清钱花在哪三类数据上、哪一项增长最快、砍掉哪些数据不影响排障。答不上来就是没治理。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。