首页/云/可观测性速查/高基数:指标爆炸的成本与治理
本包目录(282 条)
监控体系与方法40 条
Prometheus 与采集64 条Grafana 与看板53 条日志平台52 条链路追踪23 条告警与响应50 条

高基数:指标爆炸的成本与治理

序列数 = 指标名 × 标签值组合;把用户 ID、完整 URL、请求 ID 放进标签会让序列数快速膨胀,拖慢查询并推高存储与内存成本。

可观测性速查云更新于 2026-10-12
影响内存占用、TSDB 体积、查询延迟全面变差
常见来源用户级/会话级标签、未归一化的路径、动态错误消息
治理手段metric_relabel_configs 丢弃、路径归一化、标签白名单

定位高基数的常用查询

定位高基数的常用查询
# 序列数靠前的指标
topk(10, count by (__name__) ({__name__=~".+"}))

# 某个标签的基数
count(count by (path) (http_requests_total))

# 实例序列总量(TSDB 健康)
prometheus_tsdb_head_series
在采集端丢弃高基数指标比事后治理更省成本:先加 metric_relabel_configs 再观察序列数变化。

易错点

  • user_id、session_id 这类维度属于日志或链路数据,放进指标标签几乎必然失控
  • 路径未归一化(/order/88123 与 /order/99120)会让 route 标签基数随业务量增长

数据来源与参考

  • Prometheus 文档 · relabel 与存储配置
  • Prometheus FAQ · 高基数问题说明
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌