DevOps之prometheus优化

Posted 2023-03-30

参考技术A 随着业务的扩大，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值，将大大降低性能压力，提高监控效率。同时组内规则按照固定时间间隔运行，间隔时间最好也错开，这样避免查询峰值的出现。

DevOps之prometheus实现优雅的告警

参考技术A 目前prometheus的告警，常用的有grafana自带的告警和prometheus插件alertmanger的告警两种，这里测试下alertmanger的告警功能。

综合考虑，配合上prometheus operator，使用alertmanger，能够使监控告警这块的工作更加devops。

prometheus operator 在k8s中引入了自定义资源定义（CRSs）Prometheus、ServiceMonitor、PrometheusRule和Alertmanager。

所以在k8s中搭建好prometheus operator后，当我们需要监控一个项目时，我们的配置顺序是配置ServiceMonitor获取监控数据，配置PrometheusRule获取告警阈值，配置Alertmanager制定告警发送方式

如果我们已经完成了ServerMonitor的对象的编写，下面就要将监控好的重要数据，设置阈值，触发告警。

这里用spark 服务cpu使用率为例，介绍下PrometheusRule的写法

这样我们就完成一个PrometheusRule 资源对象的编写了，那么prometheus是怎么识别这个告警规则的呢。

我们先查看下prometheus的资源对象

kubectl get prometheus/k8s -n monitoring -o yaml

可以看到，prometheus会自动匹配标签为prometheus=k8s 和 role=alert-rules的prometheusRule的资源对象，这里我们可以体会到prometheus operator自动发现的魅力，我们只需要编写相应的告警规则yaml文件，然后apply一下，便可以制定告警。

在prometheus界面上面查看刚刚制定的告警规则

对于告警通知，需要考虑以下几点

及时性：邮件通知有时候不会注意，尤其是不在电脑面前，所以这里我们选择工作中使用的企业微信作为告警消息推送方式
简洁性：如果服务器性能等到达了一个warning值，会有很多相关的告警全部触发，所以这里我们需要配置分组、静默、抑制方案
容灾性：如果alermanger或者prometheus本身挂掉了，发不出告警怎么办，一般会采用另一个监控来监控prometheus，或者自定义一个持续不断的告警通知，哪一天这个告警通知不发了，说明监控出现问题了。很棒的一点是，prometheus operator已经考虑了这一点，本身携带一个watchdog，作为对自身的监控

创建一个alertmanger配置文件

删除之前的secret对象，并且创建新的

查看企业微信，这个时候会发现已经收到告警信息

这个watchdog便是对prometheus自身的监控。如果有需要，可以制定一条路由，匹配severity为none的告警，然后每24h重复一次，这样可以达到每天监控prometheus本身的效果，哪一天没收到watchdog，便可以知道prometheus挂了。

正常收到的告警信息

alertmanger也支持webhook告警，但是比如钉钉和企业微信机器人这类对消息头有特殊要求的，如果直接用webhook的话，需要安装一个插件封装下，才可以调用

Alertmanager还支持临时静默告警。有时候我们在处理告警，想要临时静默告警消息，或者测试环境中，进行压测，需要临时静默一段时间的告警，我们就可以直接通过Alertmanager的UI临时屏蔽特定的告警通知。通过定义标签的匹配规则(字符串或者正则表达式)，如果新的告警通知满足静默规则的设置，则停止向receiver发送通知
目前Alertmanager只支持在UI上面进行临时静默告警

当静默规则生效以后，从Alertmanager的Alerts页面下用户将不会看到该规则匹配到的告警信息，微信机器人也不会发送响应的告警消息