本章主要对如何使用Prometheus与Alertmanager组件集成配置,以及对警报规则 Rules 的俩种类型及其模板内容进行讲解。

与Alertmanager集成

Prometheus把产生的警报发给Alertmanager进行处理时,需要在Prometheus使用的配置文件中添加关联Alertmanager的组件的对应配置信息。

alerting:
alert_relabel_configs:
[ - <relabel_config> ... ]
alertmanagers:
[ - <alertmanager_config> ... ]
# alertmanagers 为 alertmanager_config 数组,

配置范例:

alerting:
alert_relabel_configs: # 动态修改 alert 属性的规则配置。
- source_labels: [dc]
regex: (.+)\d+
target_label: dc1
alertmanagers:
- static_configs:
- targets: ['127.0.0.1:9093'] # 单实例配置
#- targets: ['172.31.10.167:19093','172.31.10.167:29093','172.31.10.167:39093'] # 集群配置
- job_name: 'Alertmanager'
# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.
static_configs:
- targets: ['localhost:19093']

上面的配置中的 alert_relabel_configs是指警报重新标记在发送到Alertmanager之前应用于警报。 它具有与目标重新标记相同的配置格式和操作,外部标签标记后应用警报重新标记,主要是针对集群配置。

这个设置的用途是确保具有不同外部label的HA对Prometheus服务端发送相同的警报信息。

Alertmanager 可以通过 static_configs 参数静态配置,也可以使用其中一种支持的服务发现机制动态发现,我们上面的配置是静态的单实例,针对集群HA配置,后面会讲。

此外,relabel_configs 允许从发现的实体中选择 Alertmanager,并对使用的API路径提供高级修改,该路径通过 __alerts_path__ 标签公开。

完成以上配置后,重启Prometheus服务,用以加载生效,也可以使用前文说过的热加载功能,使其配置生效。然后通过浏览器,访问 http://192.168.1.220:19090/alerts 就可以看 inactive pending firing 三个状态,没有警报信息是因为我们还没有配置警报规则 rules

警报规则

警报规则 rules 使用的是 yaml 格式进行定义,在Prometheus中通过我们前面讲过的 PromQL 配置实际警报触发条件,Prometheus 会根据设置的警告规则 Ruels 以及配置间隔时间进行周期性计算,当满足触发条件规则会发送警报通知。
警报规则加载的是在 prometheus.yml 文件中进行配置,默认的警报规则进行周期运行计算的时间是1分钟,可以使用 global 中的 evaluation_interval 来决定时间间隔。

范例:

global:
evaluation_interval: 15s

警报规则可以指定多个文件,也可以自定到自定义的目录下面,为了管理更为便捷,方便阅读,可以把警报规则拆成多分,用以区分环境,系统,服务等,如:prod,test,dev 等等,并且支持以正则表达式定义。

范例:

rule_files:
#- "/data/prometheus/rules/*.yml" # 正则表达式,会加在此目录下所有警报规则配置文件
- "/data/prometheus/rules/ops.yml" # 仅加载ops.yml警报规则文件
#- "/data/prometheus/rules/prod-*.yml"
#- "/data/prometheus/rules/test-*.yml"
#- "/data/prometheus/rules/dev-*.yml"

现在开始讲告警规则 Rules 的定义,格式为YAML。

groups:
- name: <string>
rules:
- alert: <string>
expr: <string>
for: [ <duration> | default 0 ]
labels:
[ <lable_name>: <label_value> ]
annotations:
[ <lable_name>: <tmpl_string> ]
参数 描述
- name: <string> 警报规则组的名称
- alert: <string> 警报规则的名称
expr: <string 使用PromQL表达式完成的警报触发条件,用于计算是否有满足触发条件
<lable_name>: <label_value> 自定义标签,允许自行定义标签附加在警报上,比如high warning
annotations: <lable_name>: <tmpl_string> 用来设置有关警报的一组描述信息,其中包括自定义的标签,以及expr计算后的值。
groups:
- name: operations
rules:
- alert: node-down
expr: up{env="operations"} != 1
for: 5m
labels:
status: High
team: operations
annotations:
description: "Environment: {{ $labels.env }} Instance: {{ $labels.instance }} is Down ! ! !"
value: '{{ $value }}'
summary: "The host node was down 20 minutes ago"

以上就是一个完整 Rules 的配置,如果Prometheus 在周期检测中使用PromQ以env=operations为维度查询,如果当前查询结果中具有标签operations,且返回值都不等于1的时候,发送警报。
对于写好的 Rules 可以是常用 promtool 来check ruls.yml 的书写格式是否正确。

/usr/local/bin/promtool check rules /data/prometheus/rules/ops.yml
Checking /data/prometheus/rules/ops.yml
SUCCESS: 7 rules found

对于修改好的rules文件,保存以后,经过检测没有问题,直接重新热加载 Prometheus就可以在页面看到了。对于触发警报规则,比较简单了,直接修改运算值或者去停掉 node-exporter 服务,便可在界面看到警报信息。一个告警在生命周期会有三种状态

状态 描述
Inactive 正常状态,未激活警报
Pending 已满足触发条件,但没有满足发送时间条件,此条件就是上面rules范例中的 for 5m 子句中定义的持续时间
Firing 满足条件,且超过了 for 子句中的的指定持续时间5m

带有for子句的警报触发以后首先会先转换成 Pending 状态,然后在转换为 Firing 状态。这里需要俩个周期才能触发警报条件,如果没有设置 for 子句,会直接 Inactive 状态转换成 Firing状态,然后触发警报,发送给 Receiver 设置的通知人。

在运行过程中,Prometheus会把Pending或Firing状态的每一个告警创建一个 Alerts指标名称,这个可以通过Rules来触发警报测试,直接在UI中Graph查看指标 ALERTS,格式如下:

ALERTS{alertname="alert name",alertstate="pending|firing",<additional alert label>}

当警报处于激活状态 Pending 或者 Firing时候,如上图所示,样本值为1。其他状态为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> 字段配置方式略有不同,其他都是一样的。

配置范例:

- alert: ServiceDown
expr: avg_over_time(up[5m]) * 100 < 50
annotations:
description: The service {{ $labels.job }} instance {{ $labels.instance }} is
not responding for more than 50% of the time for 5 minutes.
summary: The service {{ $labels.job }} is not responding
- alert: RedisDown
expr: avg_over_time(redis_up[5m]) * 100 < 50
annotations:
description: The Redis service {{ $labels.job }} instance {{ $labels.instance
}} is not responding for more than 50% of the time for 5 minutes.
summary: The Redis service {{ $labels.job }} is not responding
- alert: PostgresDown
expr: avg_over_time(pg_up[5m]) * 100 < 50
annotations:
description: The Postgres service {{ $labels.job }} instance {{ $labels.instance
}} is not responding for more than 50% of the time for 5 minutes.
summary: The Postgres service {{ $labels.job }} is not responding

recording rules

recording rules 是提前设置好一个比较花费大量时间运算或经常运算的表达式,其结果保存成一组新的时间序列数据。当需要查询的时候直接会返回已经计算好的结果,这样会比直接查询快,同时也减轻了PromQl的计算压力,同时对可视化查询的时候也很有用,可视化展示每次只需要刷新重复查询相同的表达式即可。

在配置的时候,除却 record: <string> 需要注意,其他的基本上是一样的,一个 groups 下可以包含多条规则 rulesRecordingRules 保存在 group 内,Group 中的规则以规则的配置时间间隔顺序运算,也就是全局中的 evaluation_interval 设置。

配置范例:

groups:
- name: http_requests_total
rules:
- record: job:http_requests_total:rate10m
expr: sum by (job)(rate(http_requests_total[10m]))
lables:
team: operations
- record: job:http_requests_total:rate30m
expr: sum by (job)(rate(http_requests_total[30m]))
lables:
team: operations

上面的规则其实就是根据 record 规则中的定义,Prometheus 会在后台完成 expr 中定义的 PromQL 表达式周期性运算,以 job 为维度使用 sum 聚合运算符 计算 函数ratehttp_requests_total 指标区间 10m 内的增长率,并且将计算结果保存到新的时间序列 job:http_requests_total:rate10m 中,
同时还可以通过 labels 为样本数据添加额外的自定义标签,但是要注意的是这个 Lables 一定存在当前表达式 Metrics 中。

使用模板

模板是在警报中使用时间序列标签和值展示的一种方法,可以用于警报规则中的注释(annotation)与标签(lable)。模板其实使用的go语言的标准模板语法,并公开一些包含时间序列标签和值的变量。这样查询的时候,更具有可读性,也可以执行其他PromQL查询
来向警报添加额外内容,ALertmanager Web UI中会根据标签值显示器警报信息。

{{ $lable.<lablename>}} 可以获取当前警报实例中的指定标签值

{{ $value }} 变量可以获取当前PromQL表达式的计算样本值。

groups:
- name: operations
rules:
# monitor node memory usage
- alert: node-memory-usage
expr: (1 - (node_memory_MemAvailable_bytes{env="operations",job!='atlassian'} / (node_memory_MemTotal_bytes{env="operations"})))* 100 > 90
for: 1m
labels:
status: Warning
team: operations
annotations:
description: "Environment: {{ $labels.env }} Instance: {{ $labels.instance }} memory usage above {{ $value }} ! ! !"
summary: "node os memory usage status"

调整好rules以后,我们可以使用 curl -XPOST http://localhost:9090/-/reload 或者 对Prometheus服务重启,让警报规则生效。

这个时候,我们可以把阈值调整为 50 来进行故障模拟操作,这时在去访问UI的时候,当持续1分钟满足警报条件,实际告警状态已转换为 Firing,可以在 Annotations中看到模板信息 summarydescription 已经成功显示。

需要注意的是,一个稳定健壮的Prometheus监控系统中,要尽量使用模板化,这样会降低性能开销(Debug调试信息等),同时也易于维护。

下面网站收录了当前大部分的rules规则,大家可以对应自己的环境,配置相关服务的Rules。

[Prometheus告警规则收集(https://awesome-prometheus-alerts.grep.to/)

Prometheus监控神器-Rules篇的更多相关文章

  1. Prometheus监控神器-Alertmanager篇(1)

    本章节主要涵盖了Alertmanager的工作机制与配置文件的比较详细的知识内容,由浅入深的给大家讲解. 警报一直是整个监控系统中的重要组成部分,Prometheus监控系统中,采集与警报是分离的.警 ...

  2. Prometheus监控神器-Alertmanager篇(4)

    本章节主要讲解Alertmanager高可用的搭建与配置的详细的知识内容. 为了提升Prometheus的服务可靠性,我们会部署两个或多个的Prometheus服务,两个Prometheus具有相同的 ...

  3. Prometheus监控神器-服务发现篇(二)

    本章节讲解服务发现与Relabelling的机制与范例. 通过服务发现的方式,我们可以在不重启Prometheus服务的情况下动态的发现需要监控的Target实例信息. 如上图所示,对于线上环境我们可 ...

  4. Kubernetes容器集群管理环境 - Prometheus监控篇

    一.Prometheus介绍之前已经详细介绍了Kubernetes集群部署篇,今天这里重点说下Kubernetes监控方案-Prometheus+Grafana.Prometheus(普罗米修斯)是一 ...

  5. 《为什么说 Prometheus 是足以取代 Zabbix 的监控神器?》

    为什么说 Prometheus 是足以取代 Zabbix 的监控神器?   Kuberneteschina 致力于提供最权威的 Kubernetes 技术.案例与Meetup! ​关注他 12 人赞同 ...

  6. 监控神器-普罗米修斯Prometheus的安装

    搬砖党的福音:普罗米修斯-监控神器 功能: 在业务层用作埋点系统 Prometheus支持多种语言(Go,java,python,ruby官方提供客户端,其他语言有第三方开源客户端).我们可以通过客户 ...

  7. Prometheus监控系统之入门篇(一)续

    在上篇Prometheus监控系统之入门篇(一)中我们讲解了Prometheus的基本架构和工作流程, 并从0到1搭建了Prometheus服务,pushgateway以及告警系统. 本篇我们主要介绍 ...

  8. Prometheus监控系统之入门篇(一)

    1. 简介 Prometheus: (简称Prom)是由SoundCloud开发的开源监控报警系统.是大名鼎鼎的CNCF云原生基金会下的第二大开源项目.具有如下特点: 使用Go语言开发 内置时序数据库 ...

  9. Prometheus 监控报警系统 AlertManager 之邮件告警

    转载自:https://cloud.tencent.com/developer/article/1486483 文章目录1.Prometheus & AlertManager 介绍2.环境.软 ...

随机推荐

  1. redis(五):Redis 键(key)(python)

    # -*- coding: utf-8 -*- import redis #这个redis 连接不能用,请根据自己的需要修改 r =redis.Redis(host="123.516.174 ...

  2. keyring源码加密解密函数分析

    Encrypt the page data contents. Page type can't be FIL_PAGE_ENCRYPTED, FIL_PAGE_COMPRESSED_AND_ENCRY ...

  3. Cyber Security - Palo Alto Firewall V-Wires

    Leveraging V-Wires Bridge two physical connections and apply security Policies without influencing a ...

  4. Salesforce LWC学习(十九) 针对 lightning-input-field的label值重写

    本篇参考: https://salesforcediaries.com/2020/02/24/how-to-override-lightning-input-field-label-in-lightn ...

  5. 在docker中写个Hello World

    Hello World Docker 示例 准备hello.cpp #include<stdio.h> int main(){ printf("Hello World Docke ...

  6. 团队转型,Scrum与DevOps要如何取舍?

    团队在践行敏捷的过程中,会有多种选择:Scrum.XP.Kanban.Crystal.精益生产.规模化敏捷等,其中最流行的敏捷开发方法当属Scrum.正因如此,大部分人对其产生了刻板印象:认为敏捷就是 ...

  7. 当小程序遇见物联网IoT,几行代码搞定智能插座控制

    在 5G 热潮的推动下,与其紧密结合的物联网(IoT)正日益成为个人和企业工作生活中的重要组成部分,它为企业和个人带来了操作流程的改进和更好的生活体验,随着人工智能(AI)技术的日趋成熟,IoT 与 ...

  8. 疑难杂症1-去掉网站里的特殊编码&#65279

    编辑器:Visual Studio 2019项目框架:Net Core 3.1 + AutoFac 特殊符号&#65279,这是编码UTF-8 + BOM的特殊标记,是隐藏的,但是会被浏览器翻 ...

  9. 清晰架构(Clean Architecture)的Go微服务—重大升级

    去年,我创建了一个清晰架构(Clean Architecture)微服务框架,它功能强大,但有些重.我写了一个系列文章来讲述它,请参阅"清晰架构(Clean Architecture)的Go ...

  10. CSRF与XSS攻击的原理与防范

    CSRF 1.概念与原理 CSRF,跨站请求伪造,攻击方伪装用户身份发送请求从而窃取信息或者破坏系统.例如: 用户访问A网站登陆并生成了cookie,再访问B网站,如果A网站存在CSRF漏洞,此时B网 ...