核心在于统一命名、可控基数、标签约束和全链路协同，需从开发埋点、指标注册、采集配置到告警规则全环节对齐标准：统一dify_前缀+语义+单位（如dify_api_request_duration_seconds），禁用缩写与动词开头；标签规避高基数（禁用用户id/url等），生命周期各阶段配套机制保障规范落地。
Prometheus 监控指标的度量一致性与规范维护，核心在于统一命名、可控基数、标签约束和全链路协同。这不是靠单点配置就能解决的事，而是需要从开发埋点、指标注册、采集配置到告警规则全环节对齐标准。
指标命名必须统一前缀+语义+单位
所有自定义指标需以业务或系统域为前缀（如 dify_api_、db_、cache_），全部小写+下划线分隔；名称本身要表达“是什么”而非“怎么算”。比如：
- ✅
dify_api_request_duration_seconds（含义清晰、单位明确） - ❌
apiTimeMs（缩写歧义、单位模糊、无前缀） - ❌
getLatency（动词开头、未体现度量类型）
后缀需符合 Prometheus 社区惯例：_total表示计数器，_seconds表示持续时间，_ratio表示比例值。避免嵌入动态值（如用户 ID）到指标名中。
标签设计必须规避高基数陷阱
每个标签都应是低变动、高聚合性的维度，例如 service、region、status_code、method。禁止将以下内容作为标签：
- 用户 ID、请求 ID、URL 路径全量、长文本日志片段
- 随机生成的 UUID 或时间戳
- 变化频繁且取值数量不可控的字段
若业务确需区分个体行为（如某类任务执行耗时），应改用summary类型记录分位数，而非靠标签拆分时间序列。
指标生命周期需配套机制保障
- 注册阶段：通过封装好的指标工厂（如 Go 的
promauto.NewCounter）统一创建，禁止裸 new - 暴露阶段：HTTP
/metrics接口只暴露已注册指标，禁用运行时动态新增 - 采集阶段：Prometheus 配置中启用
honor_labels: true避免 target 标签覆盖，同时用relabel_configs清洗非法 label 值 - 告警阶段：所有 PromQL 规则须基于规范命名的指标编写，避免硬编码非标名称或临时别名
规范落地要靠工具+流程兜底
- 在 CI 流程中集成指标 lint 工具（如
promtool check metrics+ 自定义校验脚本），拦截不合规指标暴露 - 使用 ServiceMonitor / PodMonitor CRD 管理抓取配置，配合 Prometheus Operator 实现配置版本化与漂移检测
- 定期执行基数审计：查询
count by (__name__) ({__name__=~".+"})，识别异常膨胀的指标；结合label_values()分析各标签实际取值数量
不复杂但容易忽略
