高基数指标导致 Prometheus 查询慢怎么优化
Prometheus 没有直接的“基数限制开关”能自动加速查询，解决高基数导致查询慢的核心方案是在采集阶段通过 relabel 丢弃无用标签，或使用记录规则预聚合数据。
先说结论：高基数问题本质是时间序列数量过多，优化重点在于减少入库的系列数量，而不是单纯调整查询参数。
- 先定位：使用 TSDB 状态接口或 PromQL 找出基数最高的指标和标签
- 先做：在 scrape_config 中配置 metric_relabel_configs 丢弃高势标签（注意仅对新数据生效）
- 再验证：观察 head series 数量变化及查询延迟是否下降
- 注意：修改配置前务必确认 Prometheus 启动参数支持重载
核心原理
Prometheus 的 TSDB 存储引擎为每个唯一的标签组合创建一个时间序列。当某个指标包含高基数标签（如 user_id、request_id、pod 名称）时，序列数量会指数级增长。查询时，引擎需要扫描更多的索引条目和内存块，导致 CPU 和内存消耗增加，响应变慢。公开资料中没有看到可靠的量化数据说明具体多少基数会触发瓶颈，这取决于硬件配置和查询复杂度，但系列数量与查询延迟通常呈正相关。
前置条件：确保支持配置重载
在进行配置修改前，需确认 Prometheus 启动参数允许动态重载配置，否则修改后无法生效或需要重启服务。
1. 检查启动参数
确保 Prometheus 启动命令中包含以下参数：
`--web`.enable-lifecycle # 支持通过 API 重载配置
`--web`.enable-admin-api # 支持通过 API 管理 TSDB（可选，用于排查）2. 验证重载接口
在修改配置前，可先测试重载接口是否可用：
curl -X POST http://localhost:9090/-/reload如果返回 403 或无反应，说明未开启 lifecycle 参数。此时需修改启动参数并重启 Prometheus，或使用信号重载：
kill -HUP <prometheus_pid>分步处理
1. 找出高基数元凶
调用 Prometheus API 查看当前基数最高的指标。使用以下命令 curl 获取 TSDB 状态：
curl -g 'http://localhost:9090/api/v1/status/tsdb?topN=10'返回结果中关注 seriesCountByMetricName 和 labelValueCountByLabelName，找出序列数最多的指标和标签。
或者使用 PromQL 直接查询当前内存中的序列分布：
count by (__name__) ({__name__=~".+"})2. 配置采集规则丢弃标签
编辑 prometheus.yml，在对应的 job 下添加 metric_relabel_configs。
警告：避免使用 action: keep 配合正则匹配指标名，这会导致未匹配的其他所有指标被丢弃，造成监控数据大面积丢失。建议使用 labeldrop 仅丢弃特定高基数标签。
scrape_configs:- job_name: "app"metric_relabel_configs:# 安全做法：仅丢弃 trace_id 标签，保留指标和其他标签- source_labels: [trace_id]action: labeldropregex: ".+"# 或者针对特定指标丢弃 pod 标签- source_labels: [__name__]regex: "http_requests_total"action: keep- source_labels: [pod]action: labeldropregex: ".+"3. 重载配置
发送信号或调用重载接口使配置生效（需确保已配置前置条件中的启动参数）：
curl -X POST http://localhost:9090/-/reload怎么验证是否生效
1. 检查内存序列数量：查询监控指标 prometheus_tsdb_head_series，观察数值是否随时间减少。注意，由于 relabel 仅对新采集数据生效，旧数据仍需等待 compaction 或 retention 过期。
prometheus_tsdb_head_series2. 检查查询耗时：使用 Prometheus 自带的 Dashboard 或查询 prometheus_engine_query_duration_seconds，对比优化前后的查询耗时分布。
histogram_quantile(0.95, rate(prometheus_engine_query_duration_seconds_bucket[5m]))3. 再次确认基数：再次调用 /api/v1/status/tsdb 或使用 PromQL count by (label_name) ({__name__=~".+"})，确认目标标签的基数排名是否降低。
常见坑
1. 误删关键标签：丢弃标签前确认该标签未用于关键告警规则，否则会导致告警失效。建议先在测试环境验证 relabel 配置。
2. 历史数据未清理：relabel 配置仅对新采集的数据生效，历史数据中的高基数标签依然存在。如需立即清理历史数据，需使用 Admin API 删除 TSDB 块（风险较高）或等待 retention 时间过期。
3. 正则性能：在 relabel 中使用复杂的正则表达式本身也会消耗采集性能，尽量使用精确匹配或简单前缀匹配。
4. 记录规则依赖：如果使用记录规则优化查询，需确保记录规则的计算频率高于查询频率，否则无法起到预计算效果。
参考来源
- Prometheus Official Documentation, Configuration file, https://prometheus.io/docs/prometheus/latest/configuration/configuration/
- Prometheus Official Documentation, TSDB admin API, https://prometheus.io/docs/prometheus/latest/administration/api/#tsdb-stats
- Prometheus Official Documentation, Recording rules, https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/
原文链接：https://www.zjcp.cc/ask/11425.html