告警介绍
如下所示,通过在Prometheus中定义AlertRule(告警规则),Prometheus会周期性的对告警规则进行计算,如果满足告警触发条件就会向Alertmanager发送告警信息,以邮件等方式通知运维人员。
Alertmanager可以对这些告警信息进行进一步的处理,比如当接收到大量重复告警时能够消除重复的告警信息,同时对告警信息进行分组并且路由到正确的通知方。
告警规则rules
举个告警规则配置的例子,在目录/etc/prometheus/rules/
下创建告警规则文件test-alert.rules
内容如下:
groups:
- name: example
rules:
# Alert for any instance that is unreachable for >5 minutes.
- alert: InstanceDown
expr: up == 0
for: 5m
labels:
severity: page
annotations:
summary: "Instance {{ $labels.instance }} down"
description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes."
# Alert for any instance that has a median request latency >1s.
- alert: APIHighRequestLatency
expr: api_http_request_latencies_second{quantile="0.5"} > 1
for: 10m
annotations:
summary: "High request latency on {{ $labels.instance }}"
description: "{{ $labels.instance }} has a median request latency above 1s (current value: {{ $value }}s)"
修改Prometheus配置文件prometheus.yml
,添加以下配置:
rule_files:
- /etc/prometheus/rules/*.rules
重启Prometheus后访问Prometheus UI:http://127.0.0.1:9090/rules
可以查看当前以加载的规则文件。
对于上述例子,可以手动停止node exporter来模拟up == 0
时的告警。
在告警规则文件中,我们可以将一组相关的规则(rules)设置定义在一个group下。一条告警规则(rules)主要由以下几部分组成:
- alert:告警规则的名称。
- expr:基于PromQL表达式告警触发条件,用于计算是否有时间序列满足该条件。
- for:评估等待时间,可选参数。用于表示只有当触发条件持续一段时间后才发送告警。在等待期间新产生告警的状态为
PENDING
,等待期后为FIRING
。 - labels:自定义标签,允许用户指定要附加到告警上的一组附加标签。
- annotations:用于指定一组附加信息,比如用于描述告警详细信息的文字等,annotations的内容在告警产生时会一同作为参数发送到Alertmanager。
Prometheus支持模板化label和annotations的中标签的值。
通过$labels.<labelname>
变量可以访问当前告警实例中指定标签的值。$value
则可以获取当前PromQL表达式计算的样本值。
安装Alertmanager
下载地址:https://prometheus.io/download/
tar -xvf alertmanager-0.16.2.linux-amd64.tar.gz
./alertmanager
编辑Prometheus配置文件prometheus.yml
,并添加以下内容:
alerting:
alertmanagers:
- static_configs:
targets: ['localhost:9093']
Alertmanager启动后可以通过9093
端口访问UI。
配置Alertmanager
Alertmanager主要负责对Prometheus产生的告警进行统一处理,Alertmanager解压后会包含一个默认的alertmanager.yml
配置文件,内容如下所示:
global:
resolve_timeout: 5m
route:
group_by: ['alertname']
group_wait: 10s
group_interval: 10s
repeat_interval: 1h
receiver: 'web.hook'
receivers:
- name: 'web.hook'
webhook_configs:
- url: 'http://127.0.0.1:5001/'
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname', 'dev', 'instance']
在Alertmanager配置中一般会包含以下几个主要部分:
- 全局配置(global):用于定义一些全局的公共参数,如
resolve_timeout
,该参数定义了当Alertmanager持续多长时间未接收到告警后标记告警状态为resolved
(已解决); - 模板(templates):用于定义告警通知时的模板,如HTML模板,邮件模板等;
- 告警路由(route):主要定义了告警的路由匹配规则,以及Alertmanager需要将匹配到的告警发送给哪一个receiver,;
- 接收人(receivers):接收人是一个抽象的概念,它可以是一个邮箱也可以是微信,Slack或者Webhook等,接收人一般配合告警路由使用;
- 抑制规则(inhibit_rules):可以避免当某种问题告警产生之后用户接收到大量由此问题导致的一系列的其它告警通知。合理设置抑制规则可以减少垃圾告警的产生。
路由route
在上述例子中,我们只定义了一个路由,那就意味着所有由Prometheus产生的告警在发送到Alertmanager之后都会通过名为web.hook
的receiver接收。实际上,对于不同级别的告警,会有不同的处理方式,因此在route中,我们还可以定义更多的子Route。
每一个告警都会从配置文件中顶级的route进入路由树,需要注意的是顶级的route必须匹配所有告警(即不能有任何的匹配设置match和match_re),默认情况下,告警进入到顶级route后会遍历所有的子节点,直到找到最深的匹配route,并将告警发送到该route定义的receiver中。但如果route中设置continue
的值为false,那么告警在匹配到第一个子节点之后就直接停止。如果continue
为true,报警则会继续进行后续子节点的匹配。如果当前告警匹配不到任何的子节点,那该告警将会基于当前路由节点的接收器配置方式进行处理。
其中告警的匹配有两种方式可以选择。一种方式基于字符串验证,通过设置match规则判断当前告警中是否存在标签labelname并且其值等于labelvalue。第二种方式则基于正则表达式,通过设置match_re验证当前告警标签的值是否满足正则表达式的内容。
如下例子:
route:
receiver: 'default-receiver'
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
group_by: [cluster, alertname]
routes:
- receiver: 'database-pager'
group_wait: 10s
match_re:
service: mysql|cassandra
- receiver: 'frontend-pager'
group_by: [product, environment]
match:
team: frontend
分组group
Alertmanager可以对告警通知进行分组,将多条告警合合并为一个通知。这里我们可以使用group_by
来定义分组规则。基于告警中包含的标签,如果满足group_by
中定义标签名称,那么这些告警将会合并为一个通知发送给接收器。
有的时候为了能够一次性收集和发送更多的相关信息时,可以通过group_wait
参数设置等待时间,如果在等待时间内当前group接收到了新的告警,这些告警将会合并为一个通知向receiver发送。
而group_interval
配置,则用于定义相同的Gourp之间发送告警通知的时间间隔。
邮件通知
集成163邮箱通知的配置例子如下:
global:
smtp_smarthost: 'smtp.163.com:25' #163服务器
smtp_from: '[email protected]' #发邮件的邮箱
smtp_auth_username: '[email protected]' #发邮件的邮箱用户名,也就是你的邮箱
smtp_auth_password: 'XXX' #发邮件的邮箱密码
route:
group_by: ['alertname']
repeat_interval: 1h
receiver: live-monitoring
receivers:
- name: 'live-monitoring'
email_configs:
- to: '[email protected]' #收邮件的邮箱