原文来自: prometheus-book
Alertmanager的配置主要包含两个部分:路由(route)以及接收器(receivers)。所有的告警信息都会从配置中的顶级路由(route)进入路由树,根据路由规则将告警信息发送给相应的接收器。

在Alertmanager中可以定义一组接收器,比如可以按照角色(比如系统运维,数据库管理员)来划分多个接收器。接收器可以关联邮件,Slack以及其它方式接收告警信息。

Alertmanager配置概述

Alertmanager主要负责对Prometheus产生的告警进行统一处理,因此在Alertmanager配置中一般会包含以下几个主要部分:

  • 全局配置(global):用于定义一些全局的公共参数,如全局的SMTP配置,Slack配置等内容;
  • 模板(templates):用于定义告警通知时的模板,如HTML模板,邮件模板等;
  • 告警路由(route):根据标签匹配,确定当前告警应该如何处理;
  • 接收人(receivers):接收人是一个抽象的概念,它可以是一个邮箱也可以是微信,Slack或者Webhook等,接收人一般配合告警路由使用;
  • 抑制规则(inhibit_rules):合理设置抑制规则可以减少垃圾告警的产生
    其完整配置格式如下:
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    global:
    [ resolve_timeout: <duration> | default = 5m ]
    [ smtp_from: <tmpl_string> ]
    [ smtp_smarthost: <string> ]
    [ smtp_hello: <string> | default = "localhost" ]
    [ smtp_auth_username: <string> ]
    [ smtp_auth_password: <secret> ]
    [ smtp_auth_identity: <string> ]
    [ smtp_auth_secret: <secret> ]
    [ smtp_require_tls: <bool> | default = true ]
    [ slack_api_url: <secret> ]
    [ victorops_api_key: <secret> ]
    [ victorops_api_url: <string> | default = "https://alert.victorops.com/integrations/generic/20131114/alert/" ]
    [ pagerduty_url: <string> | default = "https://events.pagerduty.com/v2/enqueue" ]
    [ opsgenie_api_key: <secret> ]
    [ opsgenie_api_url: <string> | default = "https://api.opsgenie.com/" ]
    [ hipchat_api_url: <string> | default = "https://api.hipchat.com/" ]
    [ hipchat_auth_token: <secret> ]
    [ wechat_api_url: <string> | default = "https://qyapi.weixin.qq.com/cgi-bin/" ]
    [ wechat_api_secret: <secret> ]
    [ wechat_api_corp_id: <string> ]
    [ http_config: <http_config> ]

    templates:
    [ - <filepath> ... ]

    route: <route>

    receivers:
    - <receiver> ...

    inhibit_rules:
    [ - <inhibit_rule> ... ]

    在全局配置中需要注意的是resolve_timeout,该参数定义了当Alertmanager持续多长时间未接收到告警后标记告警状态为resolved(已解决)。该参数的定义可能会影响到告警恢复通知的接收时间,读者可根据自己的实际场景进行定义,其默认值为5分钟。

基于标签的告警处理路由

在Alertmanager的配置中会定义一个基于标签匹配规则的告警路由树,以确定在接收到告警后Alertmanager需要如何对其进行处理:
其中route中则主要定义了告警的路由匹配规则,以及Alertmanager需要将匹配到的告警发送给哪一个receiver,一个最简单的route定义如下所示:

1
2
3
4
5
6
route:
group_by: ['alertname']
group_wait: 10s
group_interval: 10s
repeat_interval: 1h
receiver: 'web.hook'

上面的定义的是单个的 Route ,那现在 要是有多个的 Route , 我们这样配置:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[ receiver: <string> ]
[ group_by: '[' <labelname>, ... ']' ]
[ continue: <boolean> | default = false ]

match:
[ <labelname>: <labelvalue>, ... ]

match_re:
[ <labelname>: <regex>, ... ]

[ group_wait: <duration> | default = 30s ]
[ group_interval: <duration> | default = 5m ]
[ repeat_interval: <duration> | default = 4h ]

routes:
[ - <route> ... ]

路由匹配

每一个告警都会从配置文件中顶级的route进入路由树,需要注意的是顶级的route必须匹配所有告警(即不能有任何的匹配设置match和match_re),每一个路由都可以定义自己的接受人以及匹配规则。默认情况下,告警进入到顶级route后会遍历所有的子节点,直到找到最深的匹配route,并将告警发送到该route定义的receiver中。但如果route中设置continue的值为false,那么告警在匹配到第一个子节点之后就直接停止。如果continue为true,报警则会继续进行后续子节点的匹配。如果当前告警匹配不到任何的子节点,那该告警将会基于当前路由节点的接收器配置方式进行处理。
其中告警的匹配有两种方式可以选择。一种方式基于字符串验证,通过设置match规则判断当前告警中是否存在标签labelname并且其值等于labelvalue。第二种方式则基于正则表达式,通过设置match_re验证当前告警标签的值是否满足正则表达式的内容。
如果警报已经成功发送通知, 如果想设置发送告警通知之前要等待时间,则可以通过repeat_interval参数进行设置。

告警分组

在之前的部分有讲过,Alertmanager可以对告警通知进行分组,将多条告警合合并为一个通知。这里我们可以使用group_by来定义分组规则。基于告警中包含的标签,如果满足group_by中定义标签名称,那么这些告警将会合并为一个通知发送给接收器。
有的时候为了能够一次性收集和发送更多的相关信息时,可以通过group_wait参数设置等待时间,如果在等待时间内当前group接收到了新的告警,这些告警将会合并为一个通知向receiver发送。

而group_interval配置,则用于定义相同的Group之间发送告警通知的时间间隔。
例如,当使用Prometheus监控多个集群以及部署在集群中的应用和数据库服务,并且定义以下的告警处理路由规则来对集群中的异常进行通知。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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

默认情况下所有的告警都会发送给集群管理员default-receiver,因此在Alertmanager的配置文件的根路由中,对告警信息按照集群以及告警的名称对告警进行分组。
如果告警时来源于数据库服务如MySQL或者Cassandra,此时则需要将告警发送给相应的数据库管理员(database-pager)。这里定义了一个单独子路由,如果告警中包含service标签,并且service为MySQL或者Cassandra,则向database-pager发送告警通知,由于这里没有定义group_by等属性,这些属性的配置信息将从上级路由继承,database-pager将会接收到按cluster和alertname进行分组的告警通知。

而某些告警规则来源可能来源于开发团队的定义,这些告警中通过添加标签team来标示这些告警的创建者。在Alertmanager配置文件的告警路由下,定义单独子路由用于处理这一类的告警通知,如果匹配到告警中包含标签team,并且team的值为frontend,Alertmanager将会按照标签product和environment对告警进行分组。此时如果应用出现异常,开发团队就能清楚的知道哪一个环境(environment)中的哪一个应用程序出现了问题,可以快速对应用进行问题定位。

使用Receiver接收告警信息

目前官方内置的第三方通知集成包括:邮件、 即时通讯软件(如Slack、Hipchat)、移动应用消息推送(如Pushover)和自动化运维工具(例如:Pagerduty、Opsgenie、Victorops)。Alertmanager的通知方式中还可以支持Webhook,通过这种方式开发者可以实现更多个性化的扩展支持。

集成邮件系统

邮箱应该是目前企业最常用的告警通知方式,Alertmanager内置了对SMTP协议的支持,因此对于企业用户而言,只需要一些基本的配置即可实现通过邮件的通知。

在Alertmanager使用邮箱通知,用户只需要定义好SMTP相关的配置,并且在receiver中定义接收方的邮件地址即可。在Alertmanager中我们可以直接在配置文件的global中定义全局的SMTP配置:

1
2
3
4
5
6
7
8
9
global:
[ smtp_from: <tmpl_string> ]
[ smtp_smarthost: <string> ]
[ smtp_hello: <string> | default = "localhost" ]
[ smtp_auth_username: <string> ]
[ smtp_auth_password: <secret> ]
[ smtp_auth_identity: <string> ]
[ smtp_auth_secret: <secret> ]
[ smtp_require_tls: <bool> | default = true ]

完成全局SMTP之后,我们只需要为receiver配置email_configs用于定义一组接收告警的邮箱地址即可,如下所示:

1
2
3
name: <string>
email_configs:
[ - <email_config>, ... ]

每个email_config中定义相应的接收人邮箱地址,邮件通知模板等信息即可,当然如果当前接收人需要单独的SMTP配置,那直接在email_config中覆盖即可:

1
2
3
4
[ send_resolved: <boolean> | default = false ]
to: <tmpl_string>
[ html: <tmpl_string> | default = '{{ template "email.default.html" . }}' ]
[ headers: { <string>: <tmpl_string>, ... } ]

如果当前收件人需要接受告警恢复的通知的话,在email_config中定义send_resolved为true即可。
如果所有的邮件配置使用了相同的SMTP配置,则可以直接定义全局的SMTP配置。
这里,以Gmail邮箱为例,我们定义了一个全局的SMTP配置,并且通过route将所有告警信息发送到default-receiver中:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
global:
smtp_smarthost: smtp.gmail.com:587
smtp_from: <smtp mail from>
smtp_auth_username: <usernae>
smtp_auth_identity: <username>
smtp_auth_password: <password>

route:
group_by: ['alertname']
receiver: 'default-receiver'

receivers:
- name: default-receiver
email_configs:
- to: <mail to address>
send_resolved: true

## 屏蔽告警通知
Alertmanager提供了方式可以帮助用户控制告警通知的行为,包括预先定义的抑制机制和临时定义的静默规则。

### 抑制机制

Alertmanager的抑制机制可以避免当某种问题告警产生之后用户接收到大量由此问题导致的一系列的其它告警通知。例如当集群不可用时,用户可能只希望接收到一条告警,告诉他这时候集群出现了问题,而不是大量的如集群中的应用异常、中间件服务异常的告警通知。

在Alertmanager配置文件中,使用inhibit_rules定义一组告警的抑制规则:

```yaml
inhibit_rules:
[ - <inhibit_rule> ... ]

每一条抑制规则的具体配置如下:

1
2
3
4
5
6
7
8
9
10
11
target_match:
[ <labelname>: <labelvalue>, ... ]
target_match_re:
[ <labelname>: <regex>, ... ]

source_match:
[ <labelname>: <labelvalue>, ... ]
source_match_re:
[ <labelname>: <regex>, ... ]

[ equal: '[' <labelname>, ... ']' ]

当已经发送的告警通知匹配到target_match和target_match_re规则,当有新的告警规则如果满足source_match或者定义的匹配规则,并且已发送的告警与新产生的告警中equal定义的标签完全相同,则启动抑制机制,新的告警不会发送。

1
2
3
4
5
6
7
- source_match:
alertname: NodeDown
severity: critical
target_match:
severity: critical
equal:
- node

例如当集群中的某一个主机节点异常宕机导致告警NodeDown被触发,同时在告警规则中定义了告警级别severity=critical。由于主机异常宕机,该主机上部署的所有服务,中间件会不可用并触发报警。根据抑制规则的定义,如果有新的告警级别为severity=critical,并且告警中标签node的值与NodeDown告警的相同,则说明新的告警是由NodeDown导致的,则启动抑制机制停止向接收器发送通知。

临时静默

这个是 Alertmanager UI 的功能
除了基于抑制机制可以控制告警通知的行为以外,用户或者管理员还可以直接通过Alertmanager的UI临时屏蔽特定的告警通知。通过定义标签的匹配规则(字符串或者正则表达式),如果新的告警通知满足静默规则的设置,则停止向receiver发送通知。

使用Recoding Rules优化性能

通过PromQL可以实时对Prometheus中采集到的样本数据进行查询,聚合以及其它各种运算操作。而在某些PromQL较为复杂且计算量较大时,直接使用PromQL可能会导致Prometheus响应超时的情况。这时需要一种能够类似于后台批处理的机制能够在后台完成这些复杂运算的计算,对于使用者而言只需要查询这些运算结果即可。Prometheus通过Recoding Rule规则支持这种后台计算的方式,可以实现对复杂查询的性能优化,提高查询效率。

定义Recoding rules

1
2
rule_files:
[ - <filepath_glob> ... ]

每一个规则文件通过以下格式进行定义:

1
2
groups:
[ - <rule_group> ]

一个简单的规则文件可能是这个样子的:

1
2
3
4
5
groups:
- name: example
rules:
- record: job:http_inprogress_requests:sum
expr: sum(http_inprogress_requests) by (job)

rule_group的具体配置项如下所示:

1
2
3
4
5
6
7
8
# The name of the group. Must be unique within a file.
name: <string>

# How often rules in the group are evaluated.
[ interval: <duration> | default = global.evaluation_interval ]

rules:
[ - <rule> ... ]

与告警规则一致,一个group下可以包含多条规则rule。

1
2
3
4
5
6
7
8
9
10
11
# The name of the time series to output to. Must be a valid metric name.
record: <string>

# The PromQL expression to evaluate. Every evaluation cycle this is
# evaluated at the current time, and the result recorded as a new set of
# time series with the metric name as given by 'record'.
expr: <string>

# Labels to add or overwrite before storing the result.
labels:
[ <labelname>: <labelvalue> ]

根据规则中的定义,Prometheus会在后台完成expr中定义的PromQL表达式计算,并且将计算结果保存到新的时间序列record中。同时还可以通过labels为这些样本添加额外的标签。
这些规则文件的计算频率与告警规则计算频率一致,都通过global.evaluation_interval定义:

1
2
global:
[ evaluation_interval: <duration> | default = 1m ]

当故障发生时,即时获取到异常结果是大多数用户使用监控系统的最主要的目的之一。通过Prometheus提供的告警以及告警处理能力,通过内置的告警通知能力,能过帮助用户快速实现告警的通知。同时其还提供了简单有效的扩展方式,让用户可以基于Prometheus的告警处理模式实现更多的定制化需求。

Alertmanager 配置参考

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
global:
resolve_timeout: 5m

templates:
- '/usr/local/alertmanager/wechat.tmpl'

route:
group_by: ['alertname']
group_wait: 5m
#group_wait: 1m
#同一组内警报,等待group_interval时间后,再继续等待repeat_interval时间
group_interval: 10m
#group_interval: 1m
#当group_interval时间到后,再等待repeat_interval时间后,才进行报警
repeat_interval: 1h
#repeat_interval: 1m
receiver: 'wechat'
#子路由
routes:
- receiver: 'wechat_web'
match_re:
department: 'web'
- receiver: 'wechat_api'
match_re:
department: 'api'
receivers:
- name: 'wechat'
wechat_configs:
- corp_id: 'wwbba179b20d372e'
agent_id: '1000005'
api_secret: '-CJ9QLEFxLzxt-NWYOLuy-RuX3I'
to_user: 'test1'
send_resolved: true
- name: 'wechat_web'
wechat_configs:
- corp_id: 'wwbba179b20d372e'
agent_id: '1000005'
api_secret: '-CJ9QLEFxLzxt-NWYOLuy-RuX3I'
to_user: 'test2'
send_resolved: true
- name: 'wechat_api'
wechat_configs:
- corp_id: 'wwbba179b20d372e'
agent_id: '1000005'
api_secret: '-CJ9QLEFxLzxt-NWYOLuy-RuX3I'
to_user: 'test3'
send_resolved: true