Prometheus告警收敛

随着业务的扩大，prometheus中监控的指标会越来越多，查询的频率也在不停的增加，尤其是出现长时间汇总大量的计算指标数据的时候，会出现promql超时的情况。

针对这种情况，prometheus官网提供了简化这些复杂计算的方法：recording rule

recording rule允许预先计算经常需要或计算上昂贵的表达式，并将其结果保存为一组新的时间序列。 因此，查询预先计算的结果通常比每次需要时执行原始表达式快得多。 这对于仪表板尤其有用，仪表板需要在每次刷新时重复查询相同的表达式。记录和警报规则存在于规则组中，组内的规则以固定间隔顺序运行。

1、先在Prometheus上面查询一个请求延时p50的promql，由的右上角的load time可以看出，执行这个promql，花费时间为1721ms

2、这里写一个测试用的yml文件

3、部署这个yml文件到prometheus中

4、查看优化后的监控指标

在prometheus上执行优化明细指标汇总后的rule值，由右上角的load time可以看出，执行这个rule，花费时间为159ms，查询效率提升了10倍左右

使用recording rule，将监控指标简化成对应规则，prometheus会在采集数据的过程中，在后台计算出对应规则的值并且打上时间标签。这样当仪表盘和告警规则要使用某个监控指标时，可以直接取出来使用，从而达到降低计算时间，减少性能压力的效果。但不要什么指标都加 record，很多的 metric 其实不太会查询到。同时 label 中的值不要加到 record rule 的 name 中

所以将现有的查询指标进行规则化，然后把grafana和alertmanger中使用的promql替换成简化的rule值，将大大降低性能压力，提高监控效率。同时组内规则按照固定时间间隔运行，间隔时间最好也错开，这样避免查询峰值的出现。

以上就是关于Prometheus告警收敛全部的内容，包括:Prometheus告警收敛、Prometheus的四大指标类型、DevOps之prometheus优化等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！