标签设计决定prometheus稳定性、查询性能与告警准确性；必须枚举化、禁用动态唯一值和连续型数值；层级由粗到细固定顺序，命名统一小写加下划线，单指标标签≤6～8个，需静态打标与动态重标结合。
标签不是“给指标加几个描述”，而是决定 Prometheus 能否稳定运行、查询是否快、告警是否准的底层结构。设计不合理，轻则查不到数据、告警漏报，重则存储撑爆、查询超时、整个实例不可用。
值必须枚举化，禁用动态唯一值
标签值必须是有限、稳定、有业务含义的离散项，不能随请求或用户实时变化。
- ✅ 推荐：env="prod"、idc="shanghai"、project="user-service"、tier="api"、status="200"
- ❌ 禁止：user_id="10001"、request_id="abcde-xyz"、path="/order/123456"（应规整为 endpoint="/order"）
- ⚠️ 注意：连续型数值（如 latency_ms=147.3、uptime_seconds=86400）绝不能当标签，应作为样本值保留；可用 histogram 或 summary 类型承载分布信息
层级由粗到细，固定核心维度顺序
标签键名体现监控视角的逻辑层次，便于聚合与下钻，也利于团队对齐和工具识别。
- 推荐顺序：region → idc → cluster → project → tier → endpoint（从基础设施到业务路径）
- 避免颠倒：如先写 pod_name 再写 namespace，会导致无法按 namespace 汇总；应优先保留 namespace、service 等高阶分组维度
- 命名统一：用小写字母+下划线，如 team、service、version、zone；不用模糊名 group、role、dc —— 改为 project、tier、idc
单指标标签数≤6～8个，按需裁剪
标签组合数呈乘积式增长。10个标签、平均5个取值，理论序列数近1000万，远超单实例承载能力。
- 高频过滤维度控制在 3～4 个：如 env、idc、project、tier，覆盖 90% 查询场景
- 特殊场景标签按需附加：如 canary="true"、version="v2.3"，仅在灰度或版本对比时启用
- 采集后清理冗余元标签：用 metric_relabel_configs 删除 __meta_kubernetes_pod_uid、__address__ 等非查询用标签
- 远程写前瘦身：通过 write_relabel_configs 剔除不影响分析的标签，降低远端存储压力
静态打标 + 动态重标，分阶段精准注入
标签来源分两类，需配合使用：配置时写死的静态维度，和服务发现自动带出的元标签。
- 静态标签用于环境固化维度：如 env、team、region，直接写在 static_configs.labels 中
- 元标签必须重标为业务标签：Kubernetes 自动注入的 __meta_kubernetes_namespace 需 relabel 成 namespace；__meta_kubernetes_pod_label_app → service
- 抓取前做映射规整：用 relabel_configs 把 exporter 返回的 region=us-east-1 → idc=us-east，统一标准枚举
- 避免重复打标：instance 已由 Prometheus 自动注入，无需再把 pod_ip、container_id 当标签加
不复杂但容易忽略 —— 标签体系一旦上线就难变更，历史数据会断裂、告警会失效。前期多花一小时设计，后期少踩三天坑。
