标签是维度也是成本
标签是查询与聚合的维度，也是序列数的决定因素。好的标签设计有三个特征：取值有限、含义稳定、能反映一起变化的维度。把近乎唯一的取值放进标签，会让序列数随流量增长，最终拖垮存储与查询。
先问这个维度用来做什么
设计前先明确这个维度会被用来过滤、分组还是定位。要用来分组统计的维度必须控制取值规模；只用于描述单次事件的信息，更适合放进日志与链路，而不是指标标签。
基本信息
| 推荐标签 | 任务、实例、环境、服务、接口、状态码 |
|---|---|
| 应避免 | 用户标识、会话标识、请求编号、完整访问路径 |
| 技巧 | 错误细节放日志或链路，指标只保留粗粒度分类 |
| 基数上限 | 按可接受的序列总数倒推每个维度的取值规模 |
典型使用场景
- 多环境区分：环境标签让同一套看板适配测试与生产
- 服务与接口：支撑按服务聚合与按接口下钻
- 状态码分类：用有限取值表达成功与失败类型
- 定位实例：保留实例标签用于单机排查
- 版本标识：发布对比时区分新旧版本
用重标记把路径归一化为可控维度
用重标记把路径归一化为可控维度
metric_relabel_configs:
- source_labels: [path]
regex: "/order/[0-9]+"
target_label: route
replacement: "/order/:id" # 用路径模板代替原始路径
action: replace
- regex: "(user_id|cookie|session)"
action: labeldrop # 丢弃高基数的敏感标签维度与取值规模
| 维度 | 典型取值规模 | 主要用途 |
|---|---|---|
| 任务 | 数量级为十 | 聚合与过滤 |
| 实例 | 与主机数同阶 | 定位单机 |
| 接口 | 可控枚举 | 按接口下钻 |
| 状态码 | 有限枚举 | 区分成功与失败 |
评审时要问的问题
- 这个标签的取值上限是多少，会不会随用户或流量增长
- 它会被用来分组吗，分组后的曲线数量是否可读
- 它的含义是否稳定，改语义是否应当换新指标名
- 取值的大小写与拼写是否有统一约定
查询体验取决于标签设计：看板变量能正常展开的前提，就是对应标签的基数处在可控范围。
标签值大小写与拼写不统一会把同一维度拆成多份，聚合结果出现无法解释的重复曲线，排查时很难想到是数据问题。