Prometheus监控常见问题：如何优化高基数指标？

Question

在Prometheus监控中，高基数（High Cardinality）指标是指拥有大量不同标签组合的时间序列，例如按请求路径、用户ID或设备ID划分的指标。高基数会导致存储和查询性能显著下降，甚至引发内存溢出或服务崩溃。常见的问题包括：Prometheus服务因采集大量时间序列而性能下降、查询响应缓慢、告警规则执行延迟等。因此，如何识别并优化高基数指标，成为保障Prometheus稳定运行的关键问题。

Answer 1

一、Prometheus高基数问题的定义与影响

Prometheus是一种广泛使用的开源监控系统，它通过时间序列数据库存储采集到的指标数据。在实际使用中，某些指标由于标签（Label）的组合数量庞大，形成了所谓的“高基数”（High Cardinality）现象。

例如，当某个HTTP请求计数器按用户ID（user_id）、设备ID（device_id）或请求路径（path）进行标签划分时，若这些值的数量巨大，就会导致每个唯一的标签组合都生成一个独立的时间序列。

• 典型高基数标签：user_id, session_id, request_path, client_ip 等
• 常见表现：内存占用激增、查询延迟严重、服务不稳定甚至崩溃
• 影响范围：从采集端（scrape）到存储层（TSDB），再到查询接口（API）和告警模块（Alertmanager）

二、高基数问题的识别方法

要有效应对高基数问题，首先需要能够准确识别出哪些指标或标签是造成问题的根源。以下是常见的识别手段：

1. 使用Prometheus自带的指标：如 prometheus_tsdb_head_series 和 prometheus_config_reload_success_timestamp 来观察时间序列增长趋势。
2. 分析标签维度分布：利用 PromQL 查询特定指标的标签组合数量，例如：

   count by (__name__, job) (count by (__name__, job, instance, user_id) (up))

3. 使用第三方工具辅助：如 prometheus-label-stats 或 rotor 进行标签统计分析。

指标名称	标签组合数	所属Job	是否高基数
http_requests_total	1,500,000	api-server	是
node_cpu_seconds_total	48	node-exporter	否
request_latency_seconds	900,000	web-app	是

三、高基数问题的优化策略

解决高基数问题的核心思路是减少不必要的标签组合，同时保留关键的业务维度信息。以下是一些常用的优化策略：

# 示例：在scrape配置中移除部分高基数标签
scrape_configs:
  - job_name: 'api-server'
    metrics_path: '/metrics'
    relabel_configs:
      - source_labels: [__name__, user_id]
        action: drop
        regex: 'http_requests_total;.*'

• 标签过滤：在采集阶段通过 relabel_configs 删除非必要的高基数标签。
• 标签聚合：使用 by() 聚合函数去除不重要的标签维度，例如：

  sum by (job, method) (http_requests_total)

• 使用记录规则（Recording Rules）：将高频指标预聚合为低基数指标，供后续查询使用。
• 引入外部存储方案：对于超大规模场景，可考虑将原始数据写入 Thanos、VictoriaMetrics 或 Cortex 等支持水平扩展的远程存储系统。

四、架构设计层面的预防措施

除了运行时优化外，在系统设计初期就应考虑如何避免高基数问题的发生。以下是几个推荐做法：

graph TD A[Metrics Exporter] --> B(Prometheus Server) B --> C{Is High Cardinality?} C -->|Yes| D[Filter or Aggregate Labels] C -->|No| E[Store and Alert] D --> F[Use Recording Rules] F --> G[Prometheus Server] G --> H[Remote Storage]

• 在开发阶段规范标签命名和使用标准，避免随意添加标签。
• 对关键指标进行定期审查，评估其基数增长趋势。
• 采用分层监控结构，核心指标集中管理，边缘指标分散处理。
• 结合日志、追踪等其他可观测性系统，减轻Prometheus的负担。