添加报警规则配置
警报规则 rules
使用的是 yaml 格式进行定义,在Prometheus中通过我们前面讲过的 PromQL
配置实际警报触发条件,Prometheus 会根据设置的警告规则 Ruels
以及配置间隔时间进行周期性计算,当满足触发条件规则会发送警报通知。
在 prometheus.yml
文件中加载警报规则配置,默认的警报规则进行周期运行计算的时间是1分钟,可以使用 global
中的 evaluation_interval
来决定时间间隔。
警报规则可以指定多个文件,也可以自定到自定义的目录下面,为了管理更为便捷,方便阅读,可以把警报规则拆成多份,用以区分环境,系统,服务等,如:prod,test,dev 等等,并且支持以正则表达式定义。
其中 rule_files
就是用来指定报警规则的,这里我们同样将 rules.yml
文件用 ConfigMap 的形式挂载到 /etc/prometheus
目录下面即可,比如下面的规则:(alert-rules.yml)
上面我们定义了一个名为 NodeMemoryUsage
的报警规则。
警报规则 Rules
现在开始讲警报规则 Rules 的定义,格式为YAML,一条报警规则主要由以下几部分组成:
参数 | 描述 |
- name: <string> | 警报规则组的名称 |
- alert: <string> | 警报规则的名称 |
expr: <string | 使用PromQL表达式完成的警报触发条件,用于计算是否有满足触发条件 |
| 评估等待时间(Pending Duration),用于表示只有当触发条件持续一段时间后才发送告警,在等待期间新产生的告警状态为 |
<lable_name>: <label_value> | 自定义标签,允许自行定义标签附加在警报上,比如 |
annotations: <lable_name>: <tmpl_string> | 用来设置有关警报的一组描述信息,其中包括自定义的标签,以及expr计算后的值。 |
for 属性
这个参数主要用于降噪,很多类似响应时间这样的指标都是有抖动的,通过指定
Pending Duration
,我们可以过滤掉这些瞬时抖动,可以让我们能够把注意力放在真正有持续影响的问题上。
为了让告警信息具有更好的可读性,Prometheus 支持模板化 label 和 annotations 中的标签的值,通过 $labels.变量 可以访问当前告警实例中指定标签的值,$value 则可以获取当前 PromQL 表达式计算的样本值。
下面是一个完整 Rules 的配置,如果Prometheus 在周期检测中使用PromQ以env=operations为维度查询,如果当前查询结果中具有标签operations,且返回值都不等于1的时候,发送警报。
检测rules配置
对于写好的 Rules 可以是常用 promtool 来check ruls.yml 的书写格式是否正确。
对于修改好的rules文件,保存以后,经过检测没有问题,直接重新热加载 Prometheus就可以在页面看到了。
触发警报规则
对于触发警报规则,比较简单了,直接修改运算值或者去停掉 node-exporter 服务,便可在界面看到警报信息。一个警报在生命周期会有三种状态
状态 | 描述 |
Inactive | 正常状态,未激活警报 |
Pending | 已满足触发条件,但没有满足发送时间条件,此条件就是上面rules范例中的 for 5m 子句中定义的持续时间 |
Firing | 满足条件,且超过了 for 子句中的的指定持续时间5m |
- 这里的 pending 状态是说报警规则已经得到满足了,但是持续时间还不够,这里的持续时间是通过配置文件中的 for 来设置的。如果设置了这个字段,那么就会进入 pending 状态,并且在持续时间足够的时候转换为 Firing 状态,然后触发警报;如果没有设置 for 子句,会直接从 Inactive 状态转换成 Firing状态,然后触发警报,发送给 Receiver 设置的通知人。
同时对于已经 pending 或者 firing 的告警,Prometheus 也会将它们存储到时间序列 ALERTS{} 指标中。当然我们也可以通过表达式去查询告警实例,直接在UI中Graph查看指标 ALERTS,格式如下:
样本值为1表示当前告警处于活动状态(pending 或者 firing),当告警从活动状态转换为非活动状态时,样本值则为 0。上图已经触发警报,其警报已经被转发给Alertmanager组件,此时可以在浏览器上通过可以用过9093端口访问,查看警报状态。
触发警报的过程
现在我们来说一下整理下Prometheus从收集监控指标信息到触发警报的过程
状态 | 描述 |
1.定义规则 | 在Prometheus配置中,scrape_interval: 15s,默认是1分钟,这个定义是收集监控指标信息的采集周期,同时配置对应的警报规则,可以是全局,也可以单独为某一个metrics定义 |
2.周期计算 | 对于表达式进行计算时,Prometheus中的配置中配置了 evaluation_interval: 15s,默认也是一分钟,为警报规则的计算周期,evaluation_interval 只是全局计算周期值。 |
3.1警报状态转换(pending) | 当首次触发警报规则条件成立,表达式为 true,并且没有满足警报规则中的for子句中的持续时间时,警报状态切换为 Pending |
3.2警报状态转换(firing) | 若下一个计算周期中,表达式仍为 true,并且满足警报规则中的for子句的持续时间时,警报状态转换为 Firing,即为 active,警报会被Prometheus推送到ALertmanager组件 |
3.3警报状态转换(period) | 如果在 evaluation_interval 的计算周期内,表达式还是为 true,同时满足 for子句的持续时间,持续转发到Alertmanager,这里只是转发状态到Alertmanager,并不是直接发送通知到指定通知源 |
3.4警报状态转换(resolve) | 只到某个周期,表达式 为 false,警报状态会变成 inactive ,并且会有一个 resolve被发送到Alertmanager,用于说明警报故障依解决,发送resolve信息需要自己单独在Alertmanager中定义 |
Rules类型
Prometheus 支持两种类型的 Rules ,可以对其进行配置,然后定期进行运算:recording rules 记录规则 与 alerting rules 警报规则,规则文件的计算频率与警报规则计算频率一致,都是通过全局配置中的 evaluation_interval 定义。
alerting rules
要在Prometheus中使用Rules规则,就必须创建一个包含必要规则语句的文件,并让Prometheus通过Prometheus配置中的rule_files字段加载该文件,前面我们已经讲过了。其实语法都一样,除了 recording rules 中的收集的指标名称 record: <string> 字段配置方式略有不同,其他都是一样的。
recording rules
recording rules 是提前设置好一个比较花费大量时间运算或经常运算的表达式,其结果保存成一组新的时间序列数据。当需要查询的时候直接会返回已经计算好的结果,这样会比直接查询快,也减轻了PromQl的计算压力,同时对可视化查询的时候也很有用,可视化展示每次只需要刷新重复查询相同的表达式即可。
在配置的时候,除却 record: <string> 需要注意,其他的基本上是一样的,一个 groups 下可以包含多条规则 rules ,Recording 和 Rules 保存在 groups 内,Groups 中的规则以规则的配置时间间隔顺序运算,也就是全局中的 evaluation_interval 设置。
上面的规则其实就是根据 record 规则中的定义,Prometheus 会在后台完成 expr 中定义的 PromQL 表达式周期性运算,以 job 为维度使用 sum 聚合运算符 计算 函数rate 对http_requests_total 指标区间 10m 内的增长率,并且将计算结果保存到新的时间序列 job:http_requests_total:rate10m 中, 同时还可以通过 labels 为样本数据添加额外的自定义标签,但是要注意的是这个 Lables 一定存在当前表达式 Metrics 中。
使用模板
模板是在警报中使用时间序列标签和值展示的一种方法,可以用于警报规则中的注释(annotation)与标签(lable)。模板其实使用的go语言的标准模板语法,并公开一些包含时间序列标签和值的变量。这样查询的时候,更具有可读性,也可以执行其他PromQL查询 来向警报添加额外内容,ALertmanager Web UI中会根据标签值显示器警报信息。
{{ $lable.<lablename>}} 可以获取当前警报实例中的指定标签值
{{ $value }} 变量可以获取当前PromQL表达式的计算样本值。
调整好rules以后,我们可以使用 curl -XPOST http://localhost:9090/-/reload 或者 对Prometheus服务重启,让警报规则生效。
这个时候,我们可以把阈值调整为 50 来进行故障模拟操作,这时在去访问UI的时候,当持续1分钟满足警报条件,实际警报状态已转换为 Firing,可以在 Annotations中看到模板信息 summary 与 description 已经成功显示。
需要注意的是,一个稳定健壮的Prometheus监控系统中,要尽量使用模板化,这样会降低性能开销(Debug调试信息等),同时也易于维护。
下面网站收录了当前大部分的rules规则,大家可以对应自己的环境,配置相关服务的Rules。
参考文献: