3. 标签与基数管理：深入理解标签基数对查询性能的影响

在 Prometheus 生态中，标签（Label）是数据模型的灵魂，但也是性能瓶颈的常见根源。本章将深入剖析标签基数（Cardinality）如何影响 PromQL 查询性能，并系统性地讲解如何通过 label_values 和 count by 等工具识别高基数标签，最终制定并实施有效的降基策略。

3.1 标签基数：性能的隐形杀手

标签基数是指一个标签键（Label Key）下不同标签值（Label Value）的总数。例如，标签 instance 的值为 192.168.1.1:9090、192.168.1.2:9090、192.168.1.3:9090，其基数即为 3。

高基数标签会直接导致以下性能问题：

  • TSDB 索引膨胀：每个唯一的标签值组合都会在倒排索引中创建条目，高基数标签会指数级增加索引大小，拖慢写入和查询。
  • 查询内存爆炸：PromQL 引擎在处理高基数标签的聚合操作（如 sum by）时，需要在内存中维护大量时间序列，极易触发 OOM。
  • 采集作业压力：采集器（如 Node Exporter）需要为每个高基数标签值暴露独立的指标，增加目标抓取开销。
核心原则：标签基数应控制在 10 万以内（单个指标的总序列数）。超过此阈值，必须进行降基处理。

3.2 使用 label_values 与 count by 分析高基数标签

在制定降基策略前，必须通过 PromQL 工具精准定位高基数标签。以下两种方法是最常用的诊断手段。

3.2.1 方法一：label_values 函数（Prometheus UI 原生支持）

label_values 是一个用于 Prometheus 表达式浏览器（Expression Browser）的模板函数，可以快速列出某个标签的所有唯一值。虽然它不直接返回基数数值，但通过观察返回值的数量，可以直观判断基数高低。

使用示例：

# 在 Prometheus UI 的 /graph 页面，使用 Console 模式
label_values(node_network_receive_bytes_total, device)

该查询会返回 node_network_receive_bytes_total 指标下 device 标签的所有唯一值，如 eth0、lo、docker0 等。如果返回结果超过 100 个，说明该标签基数偏高。

注意：label_values 仅适用于 Prometheus UI 的 Console 视图，不能在 Grafana 或告警规则中直接使用。在 Grafana 中，应使用 label_values() 模板变量函数。

3.2.2 方法二：count by 聚合（精确量化基数）

使用 count by 可以精确计算每个标签值的序列数量，从而量化基数。这是最推荐的分析方法。

查询示例：

# 计算每个 device 标签值下的时间序列数量
count by (device) (node_network_receive_bytes_total)

# 结果示例：
# {device="eth0"} 1
# {device="lo"} 1
# {device="docker0"} 1
# {device="veth12345"} 1
# ... 如果返回超过 100 行，说明 device 标签基数过高

进阶分析：找出所有高基数标签

以下查询可以一次性列出所有标签的基数，帮助快速定位问题：

# 使用 count by 遍历所有标签（需在 Prometheus 2.45+ 版本支持）
count by (__name__, job, instance, device, ...) (node_network_receive_bytes_total)

# 更通用的方法：使用 label_replace 和 count 组合
count by (label_name) (
  label_replace(
    label_replace(
      node_network_receive_bytes_total,
      "label_name", "$1", "device", "(.+)"
    ),
    "label_name", "$1", "instance", "(.+)"
  )
)

3.3 高基数标签识别标准

基数范围 风险等级 建议措施
< 100 低 无需处理
100 - 1,000 中 监控趋势，评估是否可降基
1,000 - 10,000 高 立即制定降基计划
> 10,000 严重 紧急降基，否则可能导致 TSDB 崩溃

3.4 标签降基策略实战

识别出高基数标签后，需要根据业务场景制定降基策略。以下是最常见的四种策略。

3.4.1 策略一：删除无用标签（如 instance）

instance 标签通常包含 IP 和端口，在动态环境中（如 Kubernetes Pod 重启后 IP 变化）基数会无限增长。如果业务不需要按具体实例查询，应直接删除。

实施方法：

  • 采集端：在 Prometheus 的 scrape_config 中使用 metric_relabel_configs 删除标签。
  • 查询端：在 PromQL 中使用 without (instance) 聚合。
# 采集端配置示例：删除 instance 标签
scrape_configs:
  - job_name: 'kubernetes-pods'
    kubernetes_sd_configs:
      - role: pod
    metric_relabel_configs:
      - source_labels: [instance]
        regex: '(.+)'
        action: labeldrop

3.4.2 策略二：标签值哈希化

对于必须保留但基数高的标签（如 pod 名称），可以使用哈希函数将其映射到固定数量的桶中。

# 使用 label_replace 将 pod 名称哈希为 100 个桶
label_replace(
  kube_pod_info,
  "pod_hash",
  "${1}",
  "pod",
  "(.+)"
) % 100

3.4.3 策略三：标签值聚合

将高基数标签的值聚合到更高层次。例如，将 device 标签从 veth12345 聚合为 veth 类型。

# 使用 label_replace 进行正则替换聚合
label_replace(
  node_network_receive_bytes_total,
  "device_type",
  "veth",
  "device",
  "veth.*"
)

3.4.4 策略四：使用 without 替代 by

在 PromQL 查询中，优先使用 without 排除高基数标签，而不是使用 by 保留低基数标签。这可以减少内存中的序列数量。

# 推荐：使用 without 排除高基数标签
sum without (instance, pod) (rate(http_requests_total[5m]))

# 不推荐：使用 by 保留低基数标签（如果低基数标签很多，效果类似）
sum by (job, namespace) (rate(http_requests_total[5m]))

3.5 降基策略对比

策略 适用场景 优点 缺点
删除无用标签 instance、pod 等动态标签 彻底消除基数问题 丢失原始信息
标签值哈希化 必须保留但基数高的标签 控制基数上限 增加查询复杂度
标签值聚合 设备类型、区域等可归类标签 保留业务语义 需要正则表达式维护
使用 without 查询时临时降基 无需修改采集配置 仅影响当前查询

3.6 案例实战：删除无用的 instance 标签

以下是一个完整的实战案例，展示如何通过删除 instance 标签将指标基数从 10 万降低到 100。

背景：某 Kubernetes 集群有 1000 个 Pod，每个 Pod 暴露 http_requests_total 指标，instance 标签包含 Pod IP（每次重启变化）。总序列数 = 1000 Pod × 10 个指标 = 10,000。

步骤：

  1. 分析当前基数：使用 count by (instance) (http_requests_total) 确认 instance 基数为 1000。
  2. 制定降基策略：业务不需要按 Pod IP 查询，决定删除 instance 标签。
  3. 修改采集配置：在 Prometheus 的 scrape_config 中添加 metric_relabel_configs 删除 instance。
  4. 验证效果：重新查询 count by (instance) (http_requests_total)，返回结果为空（标签已删除）。
  5. 调整告警规则：将原有告警规则中的 by (instance) 改为 without (instance) 或 by (job)。
效果：总序列数从 10,000 降低到 10（仅按 job 聚合），查询性能提升 10 倍以上，TSDB 写入压力显著下降。

3.7 标签基数管理最佳实践

  • 定期审计：使用 count by 每周扫描一次所有指标的标签基数，建立基线。
  • 设置告警：当某个标签基数超过阈值（如 1000）时，触发告警通知 SRE 团队。
  • 文档化标签用途：在采集配置中注释每个标签的业务含义，避免后续误用。
  • 优先在采集端降基：在 metric_relabel_configs 中删除或聚合标签，比在查询端处理更高效。
标签基数对查询性能的影响流程 高基数标签 基数 > 10,000 TSDB 索引膨胀 写入延迟增加 5x 查询内存爆炸 OOM 风险上升 降基策略 删除/哈希/聚合 性能恢复 查询延迟降低 10x 核心结论 高基数标签 → 索引膨胀 + 内存爆炸 → 降基策略 → 性能恢复

3.8 本章小结

标签基数管理是 Prometheus 性能调优的核心环节。通过 label_values 和 count by 工具，可以快速定位高基数标签；结合删除无用标签、哈希化、聚合等降基策略，能够有效控制基数，避免 TSDB 索引膨胀和查询内存爆炸。在生产环境中，建议将标签基数管理纳入日常巡检流程，并设置自动化告警，确保系统长期稳定运行。

← 上一章 📖 返回目录 下一章 →