prometheus指标设计核心是控制基数、统一语义、支撑高效查询：指标名须蛇形命名、自解释、带约定后缀；标签禁用动态唯一值，推荐有限枚举，单指标≤6～8个标签；采集时需规整裁剪标签；查询与告警依赖标签聚合而非拼接指标名。
Prometheus 监控指标的度量规范与标签管理，核心在于控制基数、统一语义、支撑高效查询。不是加得越多越细越好，而是用得准、分得清、查得快。
指标命名要清晰可读、结构化
指标名是全局唯一标识，需兼顾可读性与机器解析友好性：
- 采用蛇形命名法，全小写+下划线，如 http_requests_total、process_cpu_seconds_total
- 名称应自解释：从左到右体现领域→子系统→度量→单位，例如 cache_hit_ratio 比 cache_ratio 更明确
- 后缀有约定用途：_total 仅用于 Counter，_seconds 表示秒级时长，_bytes 表示字节数，避免混用
- 不把标签值塞进指标名里，如不用 http_get_200_requests_total，而用 http_requests_total{method="GET",status="200"}
标签设计必须规避高基数陷阱
标签是时间序列的“身份证”，错误取值会指数级膨胀数据量：
- 禁止将动态唯一值作为标签：user_id、request_id、trace_id、pod_ip、hostname 等一律排除
- 推荐使用有限枚举值：env（prod/staging/dev）、idc（shanghai/beijing/us-east）、project（web/api/batch）、tier（frontend/middleware/db）
- 单个指标标签数建议 ≤ 6～8 个，其中 3～4 个为高频过滤维度，其余按需启用（如 canary、version）
- 路径类标签应语义化归类，如把 /user/123/profile → endpoint="/user/profile"，而非保留原始 path
采集阶段做标签规整与裁剪
标签来源多样，需在抓取时统一治理，避免脏数据入库：
- 静态标签写在 static_configs.labels 中，适用于固定环境（如 env="prod"、team="payment"）
- Kubernetes 元标签（如 __meta_kubernetes_namespace）必须通过 relabel_configs 映射为业务标签（如 namespace），否则无法直接查询
- 用 labeldrop 清理冗余元标签（如 __meta_kubernetes_pod_uid、__address__），减少存储压力
- 对原始 exporter 返回的非标值做映射，例如将 region="us-east-1" → idc="us-east"，提升跨团队一致性
查询与告警依赖标签聚合，而非拼指标名
统一指标名 + 多维标签，才能实现灵活下钻与横向对比：
- 查某地域某服务的错误率：sum(rate(http_requests_total{status=~"5..", idc="shanghai", project="web"}[5m])) / sum(rate(http_requests_total{idc="shanghai", project="web"}[5m]))
- 告警规则也应基于标签组合定义，避免为每个 service 单独写一条 rule；用 group_left 或 on() 实现跨指标关联
- 看板中用 label_values() 动态生成下拉项，确保前端与后端标签体系对齐
- 定期用 count by (__name__, job) 和 count by (metric_name, label) 监控基数增长，及时发现异常标签扩散
