3. Label 设计哲学：高基数问题、标签命名规范、如何避免 Label 爆炸

在 Prometheus 生态中，Label 是 Metric 的元数据，也是告警路由、聚合与分组的核心依据。然而，Label 设计不当会直接导致时序数据库膨胀、查询性能下降、告警规则失效。本章从高基数问题、命名规范与爆炸预防三个维度，建立可观测性场景下的 Label 设计哲学。

3.1 高基数问题：时序数据库的隐形杀手

高基数（High Cardinality）是指某个 Label 的取值数量过大，导致 Prometheus 存储的时序数量呈指数级增长。每个唯一的 Label 组合都会产生一条新的时间序列，当 Label 取值达到数万甚至数百万时，存储与查询性能将急剧恶化。

3.2 标签命名规范：可读性与一致性

Label 命名直接影响告警规则的可维护性与团队协作效率。遵循以下规范可大幅降低认知成本：

• 使用小写字母 + 下划线： 如 http_method、response_status，避免驼峰或大写。
• 避免缩写歧义： svc 不如 service 清晰，ns 不如 namespace。
• 统一层级前缀： 使用 namespace、service、pod 等标准字段，与 Kubernetes 标签对齐。
• 禁止使用保留标签： __name__、job、instance 由 Prometheus 自动注入，不要手动覆盖。
• 告警专用标签： 使用 severity、team、tier 等路由标签，与 Metric Label 分离。

3.3 如何避免 Label 爆炸：四大防御策略

Label 爆炸（Label Explosion）是指 Label 数量或基数失控，导致时序数量超出系统承载能力。以下是经过生产验证的四大防御策略：

3.3.1 策略一：基数预算与准入控制

为每个 Metric 设定 Label 基数上限，超过阈值时拒绝采集或触发告警。

# Prometheus 配置示例：限制每个 Metric 的 Label 基数
# 使用 recording rule 监控基数
- record: job:metric_label_cardinality:max
  expr: |
    max by (job, __name__) (
      count by (job, __name__) ({__name__=~".+"})
    )

# 告警规则：当基数超过 1000 时触发
- alert: HighLabelCardinality
  expr: job:metric_label_cardinality:max > 1000
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "Metric {{ $labels.__name__ }} 的 Label 基数超过 1000"

3.3.2 策略二：Label 白名单与黑名单

在采集端（如 Prometheus 或 Agent）过滤不必要的 Label，只保留核心维度。

# Prometheus relabel_config 示例：只保留指定 Label
relabel_configs:
  - source_labels: [__name__]
    regex: 'http_requests_total'
    action: keep
  - source_labels: [user_id, request_id, trace_id]
    regex: '.+'
    action: drop          # 丢弃高基数 Label

3.3.3 策略三：聚合降维

使用 Recording Rule 将高基数数据预聚合为低基数 Metric，原始数据仅保留短期存储。

# Recording Rule：按 service 和 status 聚合，丢弃 user_id
- record: service:http_requests_total:sum5m
  expr: |
    sum by (service, status) (
      rate(http_requests_total[5m])
    )

3.3.4 策略四：分层存储与数据迁移

将高基数 Metric 写入单独的短期存储，低基数 Metric 保留长期存储。使用 Thanos 或 Cortex 实现分层。

3.4 实战检查清单

在每次新增 Metric 或 Label 前，对照以下清单进行评审：

1. 基数检查： 该 Label 的预期取值数量是否超过 100？超过则考虑降维或迁移。
2. 命名检查： 是否符合团队命名规范？是否与现有 Label 冲突？
3. 必要性检查： 该 Label 是否会被告警规则、仪表盘或路由使用？如果否，则删除。
4. 聚合检查： 是否可以通过 Recording Rule 预聚合来避免原始高基数存储？
5. 监控检查： 是否已配置基数告警？是否在 Grafana 中创建了基数仪表盘？