DevOps之prometheus优化

简介

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

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

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

测试

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

before

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、查看优化后的监控指标

after

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

结论

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

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