维度（Label）设计原则：高基数陷阱、低基数推荐与维度爆炸的代价
在可观测性体系中，Metric 的维度（Label）是数据聚合与告警路由的核心载体。设计不当的 Label 会直接导致存储成本飙升、查询性能劣化、告警阈值失效。本节从基数（Cardinality）视角出发，系统梳理高基数陷阱、低基数推荐策略以及维度爆炸的规避方法。
1. 基数（Cardinality）基础概念
基数指某个 Label 在时间序列中可能取值的数量。基数越高，生成的时间序列数量呈指数级增长。
| 基数等级 | Label 取值数量 | 典型示例 | 对系统影响 |
|---|---|---|---|
| 低基数 | 1 ~ 100 | severity（critical/warning/info）、region（us-east/eu-west） | 可忽略，推荐使用 |
| 中基数 | 100 ~ 10,000 | status_code（200/404/500）、method（GET/POST/PUT） | 需谨慎，控制组合数量 |
| 高基数 | 10,000 ~ 1,000,000+ | user_id、request_id、session_id、ip_address | 严重风险，应严格禁止 |
核心原则：任何取值数量随时间无限增长或与业务实体数量线性相关的 Label，都应视为高基数陷阱。一旦误用，将导致时间序列数量爆炸，存储与查询成本失控。
2. 高基数陷阱（High Cardinality Pitfalls）
高基数 Label 是 Metric 设计中最常见且最具破坏性的错误。以下为典型陷阱场景：
- 用户级维度：将
user_id、account_id、customer_id直接作为 Label。假设 10 万用户 × 10 个 Metric = 100 万时间序列。 - 请求级维度：将
request_id、trace_id、session_id加入 Label。每次请求产生新序列，永不收敛。 - 设备级维度：将
hostname、container_id、pod_name不加限制地使用。动态扩缩容场景下序列数量随实例数线性增长。 - 参数级维度：将
query_string、url_path完整保留。路径参数变化导致基数爆炸。
真实案例：某电商平台将
product_id 作为 Label 监控商品访问延迟。百万级商品 × 5 个 Metric = 500 万时间序列，导致 Prometheus 存储 OOM，告警规则评估超时。解决方案：改用 histogram 分桶 + 业务侧单独聚合。
3. 低基数推荐（Low Cardinality Recommendations）
低基数 Label 应满足：取值集合稳定、数量可控、可枚举。推荐使用以下类别：
| Label 类别 | 推荐取值 | 基数上限 | 设计理由 |
|---|---|---|---|
| 环境 | production, staging, development | ≤ 10 | 环境数量固定，不随业务增长 |
| 服务/组件 | api-gateway, user-service, payment-service | ≤ 100 | 微服务架构中服务数量可控 |
| 严重级别 | critical, warning, info | ≤ 5 | 枚举固定，语义清晰 |
| HTTP 方法 | GET, POST, PUT, DELETE, PATCH | ≤ 10 | 标准协议，取值有限 |
| 状态码分类 | 2xx, 3xx, 4xx, 5xx | ≤ 10 | 聚合后基数可控 |
| 可用区/区域 | us-east-1a, eu-west-1b | ≤ 50 | 基础设施拓扑固定 |
设计检查清单：每新增一个 Label，先问三个问题：① 这个 Label 的取值是否会超过 100？② 取值是否会随时间无限增长？③ 是否可以用其他低基数 Label 组合替代？任一答案为“是”，则需重新设计。
4. 维度爆炸的代价与规避策略
维度爆炸指多个高基数 Label 组合后，时间序列数量呈乘法级增长。假设有 3 个 Label，每个基数分别为 100、100、100，则理论序列数为 100 × 100 × 100 = 1,000,000。
4.1 维度爆炸的代价
- 存储成本：每个时间序列需存储元数据与样本数据。百万级序列 × 15 秒采集间隔 = 每日数 TB 存储。
- 查询性能：聚合查询需扫描所有序列，响应时间从毫秒级退化到分钟级。
- 告警延迟：Prometheus 等系统对高基数序列的告警规则评估周期变长，错过故障窗口。
- 运维复杂度：无法快速定位异常维度，排障效率下降。
4.2 规避策略
| 策略 | 方法 | 适用场景 |
|---|---|---|
| Label 白名单 | 只允许预定义的 Label 集合，拒绝动态 Label | 所有 Metric 设计 |
| 基数限制 | 设置 Label 基数上限（如 ≤ 100），超限则丢弃或降级 | Prometheus relabel_config 中的 cardinality 检查 |
| 聚合降维 | 将高基数 Label 聚合为低基数分类（如 user_id → user_tier） | 业务监控、用户分群 |
| 分桶/直方图 | 使用 histogram 替代高基数 Label，将连续值映射到桶 | 延迟、大小等连续指标 |
| 外部关联 | Metric 中只保留低基数 Label，高基数信息通过 Trace/Log 关联 | 需要细粒度排查的场景 |
| 采样与降采样 | 对高基数序列进行采样存储，长期存储只保留聚合数据 | 大规模集群监控 |
最佳实践：在 Metric 设计阶段，使用基数预算模型。假设总序列数上限为 100 万，每个 Metric 平均 10 个低基数 Label，则每个 Label 基数应控制在 10 以内。超出预算的 Label 必须通过聚合或外部关联解决。
5. 维度设计决策流程
以下 SVG 图展示了从业务需求到 Label 设计的决策路径，帮助规避高基数陷阱：
6. 维度爆炸规避实战：从错误到正确
以下对比展示一个典型的高基数设计及其优化方案：
| 设计阶段 | 错误设计 | 正确设计 |
|---|---|---|
| Label 定义 | user_id、request_id、product_id |
user_tier（premium/standard/free）、service_name、status_class |
| 序列数估算 | 10 万用户 × 100 万请求 = 10^11 | 3 种 tier × 10 个服务 × 5 种状态 = 150 |
| 存储成本 | 不可控，数 TB/天 | 可控，MB 级/天 |
| 告警阈值 | 无法设置有效阈值，噪声极高 | 可基于 tier 和服务设置精准阈值 |
| 排障能力 | 需额外 Trace 系统辅助 | Metric 自身即可快速定位异常维度 |
迁移建议：对于已有高基数 Metric，采用“双写 + 逐步迁移”策略。先在新 Metric 上应用低基数设计，保留旧 Metric 用于历史对比，确认无误后下线旧 Metric。避免一次性全量迁移导致监控断档。
7. 总结：维度设计黄金法则
- 法则一：Label 取值必须可枚举，且枚举数量 ≤ 100。
- 法则二：禁止将用户 ID、请求 ID、会话 ID 等业务实体标识作为 Label。
- 法则三：组合 Label 后的总时间序列数必须小于系统预算（如 100 万）。
- 法则四：高基数信息通过 Trace/Log 承载，Metric 只保留聚合维度。
- 法则五：定期审计 Label 基数，使用 Prometheus
label_replace或relabel_config进行约束。
维度设计是 Metric 可观测性的基石。遵循低基数原则，不仅能保障系统稳定性，还能让告警阈值真正反映业务状态，而非被噪声淹没。