简介
随着业务的扩大，prometheus中监控的指标会越来越多，查询的频率也在不停的增加，尤其是出现长时间汇总大量的计算指标数据的时候，会出现promql超时的情况。
针对这种情况，prometheus官网提供了简化这些复杂计算的方法：recording rule
recording rule允许预先计算经常需要或计算上昂贵的表达式，并将其结果保存为一组新的时间序列。 因此，查询预先计算的结果通常比每次需要时执行原始表达式快得多。 这对于仪表板尤其有用，仪表板需要在每次刷新时重复查询相同的表达式。记录和警报规则存在于规则组中，组内的规则以固定间隔顺序运行。
测试
1、先在Prometheus上面查询一个请求延时p50的promql，由图片的右上角的load time可以看出，执行这个promql，花费时间为1721ms
2、这里写一个测试用的yml文件
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: test
namespace: monitoring
labels:
prometheus: k8s
role: alert-rules
spec:
groups:
- name: test
rules:
- record: nginx_test
expr: histogram_quantile(0.5, sum(rate(nginx_ingress_controller_request_duration_seconds_bucket{ingress="xxxxxxxxxxx"}[30s])) by (le))
3、部署这个yml文件到prometheus中
kubectl apply -f nginx-test.yml
4、查看优化后的监控指标
在prometheus上执行优化明细指标汇总后的rule值，由右上角的load time可以看出，执行这个rule，花费时间为159ms，查询效率提升了10倍左右
结论
使用recording rule，将监控指标简化成对应规则，prometheus会在采集数据的过程中，在后台计算出对应规则的值并且打上时间标签。这样当仪表盘和告警规则要使用某个监控指标时，可以直接取出来使用，从而达到降低计算时间，减少性能压力的效果。但不要什么指标都加 record，很多的 metric 其实不太会查询到。同时 label 中的值不要加到 record rule 的 name 中
所以将现有的查询指标进行规则化，然后把grafana和alertmanger中使用的promql替换成简化的rule值，将大大降低性能压力，提高监控效率。同时组内规则按照固定时间间隔运行，间隔时间最好也错开，这样避免查询峰值的出现。
