Prometheus记录规则命名指南：多标签暴露场景下的命名咨询

1. 是否推荐将所有标签塞进规则名称的level部分？ #

绝对不推荐把a、b、c……z这类所有标签都拼接到规则名称的level部分，像a_b_c_..............._z:istio_requests:rate5m这种命名方式存在诸多问题：

• 可读性极差：过长的名称会让后续排查、维护时难以快速识别规则对应的聚合逻辑。
• 违背设计初衷：Prometheus的核心是基于标签的多维数据模型，标签本身就是用来区分不同维度数据的，硬塞进指标名完全没必要。
• 维护成本高：后续标签数量或标签值变更时，必须同步修改规则名称，极易引发混乱。

2. level部分的标签数量有什么指南？ #

Prometheus官方文档没有明确的硬性数量限制，但有清晰的设计原则：level部分是用来标识聚合的粒度层级，而非罗列所有维度标签。
比如你可以用instance、job、service、namespace这类代表聚合范围的抽象层级名称，而非把每个具体标签都加进去。一般建议level部分只保留1-3个最核心的聚合层级标识，或者用一个能概括聚合范围的名称，避免过度堆砌。

正确的做法示例 #

遵循level:metric:operation的规范，把规则命名为类似service:istio_requests:rate5m，同时让记录规则的expr处理后保留a、b、c等所有标签，通过标签来实现多维数据的区分和查询——这才是符合Prometheus设计理念的用法。

内容的提问来源于stack exchange，提问作者Sudhakar MNSR