3、维度治理原则：高基数维度识别、无用维度裁剪、维度标准化、维度降维策略
维度治理是 Traffic 指标采集从“能采”走向“采得准、存得省、查得快”的核心环节。未经治理的维度空间会指数级膨胀，导致存储成本飙升、查询性能劣化、告警噪声失控。本节围绕四项基本原则展开：高基数维度识别、无用维度裁剪、维度标准化、维度降维策略。
3.1 高基数维度识别
高基数维度（High-Cardinality Dimension）是指取值数量远超正常量级的维度，例如 user_id、request_id、session_id、device_serial。这类维度一旦被纳入标签（Label/Tag），会瞬间将时间序列数量推至百万甚至亿级，直接击穿存储与查询引擎。
| 维度类型 | 典型基数 | 风险等级 | 治理动作 |
|---|---|---|---|
| user_id | 10⁶ ~ 10⁸ | 🔴 极高 | 禁止直接作为标签，改用聚合维度或降维 |
| request_id | 10⁷ ~ 10⁹ | 🔴 极高 | 仅用于日志关联，不进入指标标签 |
| device_serial | 10⁵ ~ 10⁷ | 🟠 高 | 按型号/批次聚合后使用 |
| api_endpoint | 10² ~ 10⁴ | 🟡 中 | 标准化路径模板，去除动态参数 |
| http_method | 5 ~ 10 | 🟢 低 | 保留，基数可控 |
| status_code | ~50 | 🟢 低 | 保留，基数可控 |
识别阈值参考：当单个维度的唯一值数量超过 10⁴ 时，应触发高基数告警；超过 10⁵ 时必须立即治理。Prometheus 等时序数据库对高基数标签极其敏感，一个高基数标签即可导致整个实例 OOM。
3.2 无用维度裁剪
无用维度是指对业务分析、告警、排障没有实际价值的维度。常见无用维度包括：
- 固定值维度：所有数据点取值相同，如
env=production（单环境部署时）。 - 冗余维度：可由其他维度推导得出，如
region与az完全一一对应。 - 调试维度：仅开发阶段使用，上线后未清理，如
debug_flag、test_version。 - 内部标识维度：对业务用户无意义，如
internal_node_id、pod_uid（非必要场景）。
裁剪原则：每个维度在接入前必须回答三个问题：① 这个维度会被用于告警分组吗？② 这个维度会被用于 Dashboard 筛选吗？③ 去掉这个维度会丢失不可恢复的信息吗？三个答案均为“否”，则裁剪。
3.3 维度标准化
维度标准化解决“同名不同义、同义不同名、格式不统一”的问题。标准化包括以下层面：
| 标准化层面 | 反例 | 正例 |
|---|---|---|
| 命名规范 | service_name / svc / app 混用 |
统一为 service |
| 值格式 | 200 / 2xx / success 混用 |
统一为 2xx |
| 大小写 | Beijing / beijing / BEIJING |
统一为小写 beijing |
| 分隔符 | user_login / userLogin / user.login |
统一为下划线 user_login |
| 空值处理 | "" / null / unknown / N/A |
统一为 unknown |
# 标准化前（混乱的维度值）
http_requests_total{method="GET", path="/api/v2/user/12345/profile", status="200"}
http_requests_total{method="get", path="/api/v2/user/67890/profile", status="OK"}
# 标准化后（路径模板化 + 方法统一小写 + 状态码统一数字）
http_requests_total{method="get", path="/api/v2/user/:id/profile", status="200"}
3.4 维度降维策略
当维度无法直接裁剪或标准化时，需要采用降维策略来压缩基数。以下是四种常用策略：
- 聚合降维：将细粒度维度聚合为粗粒度维度。例如
user_id→user_tier（VIP/普通/新用户），device_serial→device_model。 - 哈希分桶：对高基数维度值进行哈希取模，映射到固定数量的桶。例如
user_id→user_bucket{0..99}，用于流量分布分析。 - 特征提取：从高基数维度中提取关键特征作为新维度。例如从
request_id中提取request_source（Web/API/Internal）。 - 标签外置：将高基数维度从指标标签中移除，放入关联的日志或事件系统，通过 TraceID 关联查询。
避坑提示：降维策略中的“哈希分桶”虽然能控制基数，但会丢失单个用户的精确可观测性。如果业务需要精确排障（如定位某个用户请求的完整链路），应优先使用“标签外置”策略，将高基数维度放入日志或 Trace 中，而非指标中。
3.5 治理原则总结
| 原则 | 核心目标 | 典型手段 | 效果指标 |
|---|---|---|---|
| 高基数维度识别 | 提前发现风险维度 | 基数扫描、阈值告警、接入评审 | 高基数维度发现率 > 95% |
| 无用维度裁剪 | 消除无效数据膨胀 | 固定值检测、冗余推导、使用率审计 | 维度数量减少 30%~60% |
| 维度标准化 | 统一语义与格式 | 命名规范、值域枚举、格式校验 | 维度一致率 > 99% |
| 维度降维策略 | 压缩高基数维度 | 聚合、分桶、特征提取、外置 | 时序基数降低 90%~99% |
实战建议：在接入新指标前，先执行“维度治理 Checklist”：① 列出所有候选维度；② 标记基数等级；③ 裁剪无用维度；④ 应用标准化规则；⑤ 对高基数维度选择降维策略。将此流程嵌入 CI/CD 门禁，从源头控制维度质量。