Prometheus 记录规则查询快了语义也要清楚一、记录规则不是为了偷懒写短查询Prometheus 查询复杂时很多团队会用 recording rules 把中间结果预计算出来。这样能减少查询压力也能让告警表达更清晰。但记录规则不是为了偷懒把 PromQL 写短而是为了把稳定语义沉淀下来。规则命名不好、维度保留不当会让后续看板和告警更难理解。好的记录规则应该表达业务含义例如服务错误率、接口 P95 延迟、实例 CPU 使用率。不要把临时查询直接固化成规则。固化之后它就会被多个看板和告警依赖改动成本会变高。二、规则链路原始指标到业务语义flowchart TD A[原始指标] -- B[PromQL 聚合] B -- C[Recording Rule] C -- D[告警规则] C -- E[Grafana 看板]记录规则要注意保留标签。保留太多标签会导致时间序列爆炸保留太少又无法定位问题。比如服务级错误率可以保留service和namespace接口级延迟可以保留route但不应保留user_id这种高基数字段。评估周期也要合理。太短会增加 Prometheus 压力太长会让告警滞后。核心告警相关规则可以 30 秒或 1 分钟容量类规则可以更长。不是所有规则都需要同一个 interval。三、规则示例命名表达层级下面是一个服务错误率记录规则示例。groups: - name: service-sli rules: - record: job:request_errors:rate5m expr: | sum by (job) (rate(http_requests_total{status~5..}[5m])) / sum by (job) (rate(http_requests_total[5m]))命名里的job:request_errors:rate5m表达了聚合维度、指标含义和窗口。团队要统一命名规范否则规则多了以后很难查。记录规则是一种公共 API命名要稳定。修改规则前要评估依赖。Grafana 看板、告警、SLO 报告可能都在用这个规则。直接改 expr 或标签会影响下游。重要规则最好走 Review。四、运维注意规则也会拖垮 Prometheus记录规则不是免费午餐。高基数、高频率、复杂正则和大范围 join 都会增加 Prometheus 压力。规则上线后要观察 Prometheus 自身的 rule evaluation duration、样本数和内存。监控系统也需要被监控。如果查询压力很大可以考虑分层 Prometheus、Thanos Ruler 或 Mimir 等方案。但在引入复杂架构前先清理无用指标、高基数标签和低价值规则。很多性能问题不是规模大而是指标治理差。最后规则要有说明文档。这个规则表示什么、用于哪些告警、窗口为什么是 5 分钟。半年后再看文档比记忆可靠。记录规则还要避免重复定义。多个团队各自写服务错误率规则窗口、标签和过滤条件略有不同最后看板数字对不上。建议把通用 SLI 规则放在统一规则库里业务团队只扩展自己的特殊指标。监控口径一致事故讨论才不会先吵数字。规则变更后也要回看告警触发情况。如果某个规则改完后告警数量暴涨或骤降必须确认是系统变化还是规则语义变了。监控规则也是生产配置。五、总结Prometheus 记录规则能提升查询性能和告警可读性但要注意语义、命名、标签维度、评估周期和自身成本。规则是监控体系的公共语言写清楚比写短更重要。
