Prometheus-Alertmanager 警报管理器-部署和设置

一、介绍

Alertmanager 用于接收 Prometheus 推送的警报信息，并对这些警报信息进行分组、路由、删除重复数据等处理，还可以进一步设置某些警报的静默，抑制等。最后还可以使用邮件，Webhook 方式等发送通知。

在这里插入图片描述

二、核心概念

1 Grouping 分组

分组将性质相似的警报分类到单个通知中。这在多个系统同时发生故障的较大中断期间特别有用，并且数百到数千个警报可能会同时触发。

试想一个部署有 MySQL 的服务器网络中断，导致 k8s 集群中所有应用示例无法连接到这台MySQL。假设 k8s 集群中有成百上千个应用实例，将会同时发送警报信息到 Alertmanager。

其实作为管理者，只想获得一个警报信息即可，并且可以看到都有哪些实例受到影响。因此 Alertmanager 可以配置按机器和警报名称进行分组，以便发送一条比较紧凑、有汇总的通知。

2 Inhibition 抑制

抑制是指如果某些其他警报已经启动，则抑制某些警报的通知的概念。
某些其他警报和某些警报是存在一定的关联性。

例如：正在触发警报，通知无法访问整个群集。Alertmanager可以配置为，如果该特定警报正在启动，则将与该集群有关的所有其他警报静音。这将阻止数百或数千个与实际问题无关的触发警报的通知。

抑制可通过Alertmanager的配置文件进行配置。

3 Silences 静默（静音）

静默是在给定时间内简单地静音警报的一种简单方法。
静默是基于匹配器配置的，就像路由树一样。将检查传入警报是否与激活状态的静默的所有条件相等或正则表达式相匹配。如果符合或者匹配，则不会发出该警报的通知。

静默是在Alertmanager的web界面中配置的。

5 High Availability 高可用性

Alertmanager支持为实现高可用性而创建集群的配置。这可以使用 --cluster-*标志进行配置。

重要的是不要在Prometheus及其AlertManager之间进行流量负载平衡，而是将Prometheus指向所有AlertManager的列表。

要创建警报管理器的高可用性集群，实例需要配置为相互通信。这是使用标志配置的。--cluster.*

--cluster.listen-address 字符串：集群监听地址（默认为 “0.0.0.0:9094”; 空字符串 “” 表示禁用 HA 模式）
--cluster.advertise-address 字符串：集群公告地址
--cluster.peer 值`：初始对等体（对每个附加对等方重复标志）
--cluster.peer-timeout 值：对等超时期限（默认为“15s”）
--cluster.gossip-interval 值：集群消息传播速度（默认为“200ms”）
--cluster.pushpull-interval 值：值越低，值越大以牺牲带宽为代价的收敛速度（默认为“1m0s”）
--cluster.settle-timeout 值：等待群集的最长时间在评估通知之前要解决的连接。
--cluster.tcp-timeout 值：TCP 连接、读取和写入的超时值（默认为“10s”）
--cluster.probe-timeout 值：在标记节点不正常之前等待 ACK 的时间（默认为“500ms”）
--cluster.probe-interval 值：随机节点探测器之间的间隔（默认“1s”）
--cluster.reconnect-interval 值：尝试重新连接到丢失的对等体之间的间隔（默认为“10s”）
--cluster.reconnect-timeout 值：尝试重新连接到丢失的对等体的时间长度（默认值：“6H0m0s”）
--cluster.label 值：标签是要包含在每个数据包和流上的可选字符串。它唯一标识集群并防止发送八卦消息时出现交叉通信问题（默认：“”）

高可用架构图
在这里插入图片描述

三、部署

1 二进制方式

下载

在 Prometheus 下载页面可以找到不同的版本和适合不同平台的二级制部署包
这里以 Linux amd64 为例。

curl -o alertmanager.tgz -L https://github.com/prometheus/alertmanager/releases/download/v0.26.0/alertmanager-0.26.0.linux-amd64.tar.gz

1
2

配置 systemd

命令行启动参数

参数	含义
`--config.file="alertmanager.yml"`	指定配置文件
`--storage.path="data/"`	指定数据存储基础路径
`--data.retention=120h`	数据保留时长
`--web.listen-address=:9093`	用于公开度量和web界面的地址。
`--web.external-url=WEB.EXTERNAL-URL`	指定一个 FQDN ，比如 --web.external-url=http://grafana.host.com ，这样警报信息中会包含查看当时这个警报的图形链接。

命令行的所有配置参数可以使用此命令获取： alertmanager -h

[Unit]
Description=Alertmanager 警报管理器
After=network-online.target
Wants=network-online.target

[Service]
#EnvironmentFile=-
ExecStart=/usr/local/bin/alertmanager

KillSignal=SIGQUIT

Restart=always

RestartPreventExitStatus=1 6 SIGABRT

TimeoutStopSec=5
KillMode=process
PrivateTmp=true
LimitNOFILE=1048576
LimitNPROC=1048576

[Install]
WantedBy=multi-user.target

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

2 docker-compose 方式

version: "3.9"
services:
  alertmanager:
    user: "65534"
    image: quay.io/prometheus/alertmanager
    command: --config.file=/etc/alertmanager/alertmanager.yml --storage.path=/alertmanager --web.listen-address=:9093 --web.listen-address=:9098
    volumes:
      - "./config/:/etc/alertmanager"
      - "./data:/alertmanager"
    network_mode: "host"
    expose:
      # web 端口
      - "9093"
      # 集群端口
      - "9094"
      # 还是 web 端口
      - "9098"

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

--web.listen-address= 参数可以使用多次指定多个

四、配置

配置文件中一般配置静默规则、通知路由，通知接收器等。

Alertmanager 和 Prometheus 一样支持热加载配置，只需要向进程发送信号：SIGHUP 或者向服务发送POST 请求

curl -X POST http://ip:9093/-/reload

如果配置文件中有错误，配置文件将不会更新。

1 配置文件介绍

下面是一些配置示例，覆盖了最主要的基础配置, 这里有完整的配置说明

1.1 全局配置

global:
  # 用于发送电子邮件的默认SMTP智能主机，包括端口号.
  # 端口号通常为 25 或者 TLS 的 SMTP 为 465
  smtp_smarthost: 'stmpt.126.com:25' 
  # 默认的SMTP发件人标头字段
  smtp_from: 'xxx@126.com'
  
  # 要显示给SMTP服务器的默认主机名。
  [ smtp_hello: '126.com' | default = "localhost" ]
  
  # 使用CRAM-MD5、LOGIN和PLAIN的SMTP身份验证用户名，一般是邮箱的用户名。
  # 如果为空，则Alertmanager不会对SMTP服务器进行身份验证。如果 SMTP 需要认证，则会失败。
  # 此邮箱需在其邮箱服务器上开通 SMTP 功能。
  [ smtp_auth_username: 'xxx@126.com' ]
  
  # 身份验证秘钥，不是登录密码。
  [ smtp_auth_password: > ]
  
  # 发送邮件是否使用 TLS, 如果是true ，smtp_smarthost 的值中的端口应该是 465
  # 请注意，Go不支持到远程 SMTP 服务器的未加密连接。
  [ smtp_require_tls: > | default = true ]

  # 如果警报不包括EndsAt，ResolveTimeout是alertmanager使用的默认值。
  # 经过这段时间后，如果警报尚未更新，它可以将其声明为已解决。
  # 这对普罗米修斯的警报没有影响，因为它们总是包括EndsAt。
  [ resolve_timeout: > | default = 5m ]


# 从中读取自定义通知模板定义的文件。
# 最后一个元素可以使用通配符匹配器，例如 'templates/*.tmpl'
templates:
  [ - > ... ]

# 路由的根节点，称为根路由.
route: >

# 通知接收者的列表。这里可以配置邮件、webhook 等接收告警消息者。
receivers:
  - > ...

# 一个包含一个或多个静默规则的列表.
inhibit_rules:
  [ - > ... ]

# 指定可在路由树 "active_time_intervals" 字段中引用的时间间隔名称，以便在一天中的特定时间静音/激活特定路由。
# 具体如何设置，继续参看接下来的章节
time_intervals:
  [ - > ... ]
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

1.2 `receiver` 接收器

标准接收器相关设置

接收器是一个或多个通知集成的命名配置。
包含如下字段：

receivers:
  # 接收器的唯一名称。
  - name: >
    # 多个通知集成的配置，如下仅展示和介绍经常使用的几种。
    email_configs: # 发邮件
      [ - >, ... ]
    webhook_configs: # 利用 webhook 发送钉钉消息
      [ - >, ... ]
    wechat_configs: # 发企业微信
      [ - >, ... ]
1
2
3
4
5
6
7
8
9
10

接收器集成设置

这些设置允许配置特定的接收器集成。

# 是否通知已解决的警报。
[ send_resolved: > | default = false ]

# 接收警报信息的邮件地址，多个用英文逗号分开。例如： 'xxx@qq.com,yyy.@qq.com'
to: >

# 向接收人展示的发件人的地址。
[ from: > | default = global.smtp_from ]

# 发送电子邮件的SMTP主机。
[ smarthost: > | default = global.smtp_smarthost ]

# 要标识给SMTP服务器的主机名。
[ hello: > | default = global.smtp_hello ]

# SMTP身份验证信息
[ auth_username: > | default = global.smtp_auth_username ]
[ auth_password: > | default = global.smtp_auth_password ]

# SMTP TLS要求。
# 请注意，Go不支持到远程SMTP终结点的未加密连接
[ require_tls: > | default = global.smtp_require_tls ]

# TLS configuration.
tls_config:
  [ > ]

# 电子邮件通知的HTML正文，这里一般使用定义好的模板，这里的 email.default.html 是模板名称.
# 模板名称是在全局的 "templates" 字段指定的模板文件中定义的。
[ html: > | default = '{{ template "email.default.html" . }}' ]
# 电子邮件通知的文本正文。
[ text: > ]

# 其他邮件头电子邮件头键/值对。
[ headers: { : >, ... } ]
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

示例

receivers:
- name: 'team-X-mails'
  email_configs:
  - to: 'team-X+alerts@example.org, team-Y+alerts@example.org'

- name: 'team-X-pager'
  email_configs:
  - to: 'team-X+alerts-critical@example.org'
  pagerduty_configs:
  - routing_key: -X-key>

- name: 'team-Y-mails'
  email_configs:
  - to: 'team-Y+alerts@example.org'
    headers:
      subject: "邮件标题"
      from: "邮件来自哪儿"
      to: "发给谁的"
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

webhook接收器允许配置通用接收器。

如果发送钉钉，需要配合一个插件 prometheus-webhook-dingtalk

prometheus-webhook-dingtalk 会启动一个服务，并暴露一个接口。

alertmanager 可以通过 webhook_config 中的 url 字段的配置，向 prometheus-webhook-dingtalk 发送一个 POST 的 HTTP 请求。从而实现警报信息向钉钉发送的目的。

# 是否通知已解决的警报。
[ send_resolved: > | default = true ]

# 要向其发送HTTP POST请求的端点。
url: >

# 要包含在单个webhook消息中的最大警报数。超过此阈值的警报将被截断。
# 将其保留为默认值0时，将包括所有警报。
[ max_alerts: > | default = 0 ]
1
2
3
4
5
6
7
8
9

Alertmanager将以以下JSON格式向配置的端点发送HTTP POST请求：

{
  "version": "4",
  "groupKey": <string>,              // key identifying the group of alerts (e.g. to deduplicate)
  "truncatedAlerts": <int>,          // how many alerts have been truncated due to "max_alerts"
  "status": "",
  "receiver": <string>,
  "groupLabels": <object>,
  "commonLabels": <object>,
  "commonAnnotations": <object>,
  "externalURL": <string>,           // backlink to the Alertmanager.
  "alerts": [
    {
      "status": "",
      "labels": <object>,
      "annotations": <object>,
      "startsAt": "",
      "endsAt": "",
      "generatorURL": <string>,      // identifies the entity that caused the alert
      "fingerprint": <string>        // fingerprint to identify the alert
    },
    ...
  ]
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

其实，webhoook_config 的配置不仅仅支持钉钉，它是一个通用的 webhook 工具。有一个与此功能集成的列表。

要实现钉钉告警，需要安装一个钉钉插件的 webhook 服务，具体点击链接

微信通知通过微信API发送。

# Whether to notify about resolved alerts.
[ send_resolved: > | default = false ]

# The API key to use when talking to the WeChat API.
[ api_secret: > | default = global.wechat_api_secret ]

# The WeChat API URL.
[ api_url: > | default = global.wechat_api_url ]

# The corp id for authentication.
[ corp_id: > | default = global.wechat_api_corp_id ]

# API request data as defined by the WeChat API.
[ message: > | default = '{{ template "wechat.default.message" . }}' ]
# Type of the message type, supported values are `text` and `markdown`.
[ message_type: > | default = 'text' ]
[ agent_id: > | default = '{{ template "wechat.default.agent_id" . }}' ]
[ to_user: > | default = '{{ template "wechat.default.to_user" . }}' ]
[ to_party: > | default = '{{ template "wechat.default.to_party" . }}' ]
[ to_tag: > | default = '{{ template "wechat.default.to_tag" . }}' ]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

1.3 time_interval 时间间隔

`time_interval`

指定可在路由树中引用的命名时间间隔，以表示在一天中的特定时间处于静音或者激活状态的特定路由。

time_intervals:
  # 一个 time_interval 开始
  - name: >  # 此时间间隔的名称,可以在子路由中被引用。
    time_intervals:
      # 下面定义一个一个的时间间隔
      [ - > ... ]
  # 一个time_interval 结束
1
2
3
4
5
6
7

`time_interval_spec`

包含时间间隔的实际定义。语法支持以下字段：

time_intervals:
  - name: >  # 此时间间隔的名称,可以在子路由中被引用。
    time_intervals:
      - times:
        [ - > ...]
        weekdays:
        [ - > ...]
        days_of_month:
        [ - > ...]
        months:
        [ - > ...]
        years:
        [ - > ...]
        location: >
1
2
3
4
5
6
7
8
9
10
11
12
13
14

所有字段都是列表。在每个非空列表中，必须满足至少一个元素才能与字段匹配。

如果未指定字段，则任何值都将与该字段匹配。

为了使某个瞬间的时间与完整的时间间隔相匹配，所有字段都必须匹配。

如果未指定时区，则时间以UTC为单位。

一些字段支持区间和负指数，详情如下。

`time_range`

包含开始时间和不包含结束时间的范围，可以方便地表示在小时边界上开始/结束的时间。
例如，start_time:'17:00' 和 end_time:'24:00' 将从 17:00 开始，并在 24:00 之前结束。它们是这样规定的：

time_intervals:
  - times:
    - start_time: HH:MM
      end_time: HH:MM
1
2
3
4

`weekday_range`

一周中的日期列表，一周从周日开始，到周六结束。应按名称指定日期（例如“Sunday”）。

为了方便起见，还接受形式为:的范围，并且范围两端都包含。
例如：要表示: 星期一到星期三，星期六，星期日，应写成：['monday:wednesday','saturday', 'sunday']

`days_of_month_range

一个月中的数字天数列表。

天数从1开始。负值也可以接受，从月底开始，例如1月份的-1表示1月31日。
例如：['1:5'，'-3:-1']。超过月初或月底将导致它被钳制。
例如，在2月份指定 ['1:31'] 将根据闰年将实际结束日期固定为28或29。包括两端。

`month_range`

由不区分大小写的名称（例如“January”）或数字标识的日历月份列表，其中January=1。

也可接受范围。例如，['1:3'，'may:august'，'december']。包括两端。

`year_range`

年份的数字列表。接受范围。例如，["2020:2022"，"2030"]。两端均包含。

`location`

与IANA时区数据库中的位置匹配的字符串，例如东八区，即中国时区：Asia/Shanghai。

    location: 'Asia/Shanghai'
1

您也可以使用 'Local' 表示使用 Alertmanager 运行的机器作为本地时间的位置, 或使用 'UTC' 表示UTC时间。

如果未提供时区，则时间间隔以UTC时间为单位。

注意：在Windows上，只有 'Local ' 或 'UTC' 才受支持，除非您使用 ZONEINFO 环境变量提供自定义时区数据库。

关于中国时区，可以参考这篇知乎的文章 https://zhuanlan.zhihu.com/p/450867597

1.4 路由相关配置

通过与路由相关的设置，可以根据时间配置警报的路由、聚合、抑制和静音方式。

根路由

route 块定义路由树中的节点及其子节点。

如果子节点中的某些可选配置未设置，那些可选的配置参数（就是用中括号括起来的配置参数）将从其父节点继承。

每个警报都进入配置的顶级路由的路由树，该路由树必须匹配所有警报（即没有任何配置的匹配器）。

然后它遍历子节点。如果 continue 设置为 false，则在第一个匹配的子路由之后就停止继续匹配。

如果 continue 为 true，则警报将继续与后续同级路由匹配。

如果警报与节点的任何子节点都不匹配（没有匹配的子节点或不存在），则会根据当前节点的配置参数来处理警报,一般会由默认 route 块配置的 receiver 处理。

# 根路由，每个传入的警报都会经过这里
route:
  # 根路由不能有任何匹配器，因为它是所有警报的入口点。
  # 它需要配置一个默认的接收器，以便将与任何子路由不匹配的警报发送给此接收器。
  # 其值需要是全局 receivers 中配置的其中一个。
  [ receiver: > ]
  
  # 传入警报分组所依据的标签。
  # 例如 含有 cluster=A 和 alertname=LatencyHigh 标签的多个警报将被批处理到一个组中。

  # 若要按所有可能的标签进行聚合，请使用特殊值"..."作为唯一的标签名称，例如：group_by:['...']
  # 这有效地完全禁用了聚合，按原样传递所有警报。
  # 这不太可能是你想要的，除非你的警报量很低，或者你的上游通知系统执行自己的分组。
  group_by: ['alertname', 'cluster']
  
  # 当传入警报创建新的警报组时，请至少等待 "group_wait" 时间后再发送初始通知。
  # 这种方式可以确保您在 "group_wait" 时间内获得同一组的多个警报，这些警报在这个时间内进行批处理后，再一起开始触发。
  group_wait: 30s

  # 百度翻译：发送 有关添加到已发送初始通知的警报组中的新警报的通知之前等待的时间。
  # 自己的理解：基本意思就是 对于一个已经发送过初始通知的组，再次发送新的警报需要等待的时间。
  # 通常 5m 或者更长
  # 这个附上原文
  # How long to wait before sending a notification about new alerts 
  # that are added to a group of alerts for which an initial notification has already been sent.
  group_interval: 5m

  # 如果已成功发送警报通知，则在再次发送通知之前等待多长时间。（通常约3小时或更长时间）。
  # 请注意，此参数由Alertmanager的“--data.reduration”配置标志隐式绑定。通知将在repeat_interval或数据保留期结束后重新发送，以先发生的为准`repeat_interval`不应小于`group_interval'。
  repeat_interval: 3h

  # 警报是否应继续匹配后续同级节点。
  [ continue: > | default = false ]

  # 警报必须满足的匹配器列表才能匹配节点, 一般在子路由中设置。
  matchers:
    [ - > ... ]

  # 路由应该静默的时间。
  # 与全局设置 "time_intervals" 字段中定义的静音时间间隔的名称相匹配。
  # 此外，根节点不能有任何静音时间。
  # 当路由被静音时，它不会发送任何通知，但在其他情况下会正常工作（包括如果未设置“continue”选项，则结束路由匹配过程）
  mute_time_intervals:
    [ - > ...]
    
  # 路由应处于活动状态的时间。它们必须与全局设置 "time_intervals" 字段中定义的时间间隔的名称相匹配。
  # 空值表示路线始终处于活动状态。 此外，根节点不能有任何 active times。
  # 路由将仅在活动时发送通知，但在其他情况下正常运行（包括如果未设置 "continue" 选项，则结束路由匹配过程）。
  active_time_intervals:
    [ - > ...]

  # 以上所有属性都由所有子路由继承，并且可以在每个路由上覆盖。
  # 一个或者更多子路由
  routers:
    [ - > ...]
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
49
50
51
52
53
54
55

标签匹配器 `matcher`

标签匹配器是用在 routes and inhibition rules 之间进行警报的匹配。
也就是使用标签匹配器配置了匹配的规则，如果哪个警报中所包含的标签和匹配的规则相符合，就代表此警报是要处理的警报，如果某个子路由中使用此匹配器，那就是此子路由要处理这个警报，如果某个 inhibition rules 中使用了此匹配器，那就是这个 inhibition rules 处理此警报。

匹配器是一个字符串，具体语法由三个标记组成：

有效的标签名
=, !=, =~, or !~ 中其中的一个运算符。=~ 和 !~ 用于正则表达式的匹配和不匹配。
运算符后面是 UTF-8字符串，可以用双引号括起来。在每个标记之前或之后，可能存在任意数量的空白。

运算符右边的内容可以是空字符串，支持反斜杠转义规则。

当有多个匹配器规则时候，他们的书写语法是将每一个规则放在一个 yaml 语法的列表中，它们之间的关系是 and。这意味着在针对给定警报上的标签进行测试时，匹配器的所有规则评估结果必须为“true”。例如，具有以下标签的警报：

{"project":"beijing","service":"mysql"}
1

必须使用如下匹配器规则进行匹配

route:
  routers:
    - matchers:
        - project = beijing
        - service = mysql
1
2
3
4
5

下面使用正则表达式的匹配规则也是可以的

route:
  routers:
    - matchers:
        - project = beijing
        - service =~ "mysql|postgresql"
1
2
3
4
5

当然将上述匹配规则写成一行，使用 [] 进行包裹也是可以的。

route:
  routers:
    - matchers:[project = beijing, service =~ "mysql|postgresql"]
1
2
3

将匹配规则内层在包上一层大括号也是支持的。

route:
  routers:
    - matchers:['{project=beijing, service=~ "mysql|postgresql"}']
1
2
3

`routers`子路由配置

  # 具体的一个一个的子路由树.
  routes:
  # 此子路由使用正则表达式进行匹配，凡是警报的标签 service 的值是 foo1 或者 foo2 或者 baz 的警报就会
  # 走这个子路由
  - matchers:
    - service = ^(foo1|foo2|baz)$
    
    # 凡是走这个子路由的警报，使用如下的接收器接收警报信息， team-X-mails 是在全局中的 receivers 配置块中定义的
    # 一个接收器名称。 
    receiver: team-X-mails

    # 子路由中可以嵌套一个或者多个子路由
    # 当这个子路由中出现包含并且匹配标签 "severity" 的值是 "critical" 的，
    # 将警报信息从 "team-X-pager" 接收器发送出去。
    # 否则还是返回给父级路由中定义的接收器 "team-X-mails" 发送警报。
    routes:
    - matchers:
        - severity = critical
      receiver: team-X-pager

  - matchers:
      - service = files
    receiver: team-Y-mails

    # 同样这个是在符合 "service" 的值是 "files" 中的警报中，再挑选出配置 "severity: critical" 的警报
    # 从接收器 team-Y-pager 发送警报信息。否则继续返回给父级定义的接收器 team-Y-mails 发送出去警报信息。
    routes:
    - matchers:
        - severity = critical
      receiver: team-Y-pager

  # This route handles all alerts coming from a database service. If there's
  # no team to handle it, it defaults to the DB team.
  - matchers:
      - service = database

    receiver: team-DB-pager
    # Also group alerts by affected database.
    group_by: [alertname, cluster, database]

    routes:
    - matchers:
        - owner = team-X
      receiver: team-X-pager

    - matchers:
        - owner = team-Y
      receiver: team-Y-pager
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

示例：


#根路具有的所有参数，如果子路由中未设置这些参数，则这些参数将由子路由继承。
route:
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  group_by: [cluster, alertname]
  receiver: 'default-receiver'
  # 所有与以下子路由不匹配的警报都将保留在根节点上，并使用接收器 "default-receiver" 发送警报信息。
  routes:
  # 所有service=mysql或service=casandra的警报都使用接收器 "database-pager" 发送警报信息
  - receiver: 'database-pager'
    group_wait: 10s
    matchers:
    - service=~"mysql|cassandra"
  #所有带有 team="frontend" 标签的警报都匹配此子路由.
  # 它们按 product 和 environment 分组，而不是按根路由中定义的 cluster 和 alertname 分组。
  # 并使用接收器 "frontend-pager" 发送警报信息。
  - receiver: 'frontend-pager'
    group_by: [product, environment]
    matchers:
    - team="frontend"

  # 所有带有service=inhouse服务标签的警报都与此子路由匹配。
  # 该路线将在下班时间和节假日期间静音。
  # 即使匹配，它也将继续到下一个子路线
  - receiver: 'dev-pager'
    matchers:
      - service="inhouse-service"
    mute_time_intervals:
      - offhours
      - holidays
    continue: true

    # 所有带有  service=inhouse-service 标签的警报都与此子路由匹配
    # 该路由将仅在非工作时间和节假日期间有效。
  - receiver: 'on-call-pager'
    matchers:
      - service="inhouse-service"
    active_time_intervals:
      - offhours
      - holidays
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

1.5 抑制相关配置 Inhibition

这允许在系统或服务之间建立依赖关系，以便在中断期间，仅发送一组互连警报中最相关的警报。
例如，一台服务器网络中断，同时也配置的这台服务器上的相关服务的状态检查等警报，那只需要发送此服务器网络中断的警报即可,服务器上的服务的状态告警可以被处理为静音，因为服务器上的服务状态的检查依赖此服务器的网络。

抑制规则允许在一个或多个匹配了 source_matchers 定义的匹配规则的警报正在触发的情况下，使一组匹配了 target_matchers 定义的匹配规则的警报静默。

从语义上讲，缺失的标签和值为空的标签是一回事。因此，如果源警报和目标警报中都缺少以等号列出的所有标签名称，则将应用禁止规则。

为了防止警报抑制自身，与规则的目标端和源端匹配的警报不能被相同情况的警报（包括自身）抑制。但是，我们建议选择目标和源匹配器，以使警报永远不会同时匹配双方。它更容易推理，而且不会引发这种特殊情况。

# 使抑制生效的匹配规则。
# 至少需要有一个警报完全匹配如下列表中的匹配规则，抑制才会生效。
source_matchers:
  [ - > ... ]
# 同时满足的如下列表中匹配规则的所有警报将会被静音。
target_matchers:
  [ - > ... ]

# 匹配 source_matchers 的源警报和匹配 target_matchers 的目标警报中，它们的标签名必须都含有 equal 值中的标签名,且标签值必须相等，才会使抑制生效。
[ equal: '[' , ... ']' ]

1
2
3
4
5
6
7
8
9
10
11

示例

#如果同一警报的级别已经是严重级别，我们将任何 warning 级别的通知都设为静默。
inhibit_rules:
- source_matchers:
    - severity="critical"
  target_matchers:
    - severity="warning"
  # 如果警报名称相同，则应用抑制。
  # 注意：
  #   如果源警报和目标警报中都缺少“equal”中列出的所有标签名称，则将应用抑制规则！
  equal: ['alertname']

1
2
3
4
5
6
7
8
9
10
11

2 静默配置

静默是可以让一个或多个警报在指定的某个时间段进入静默状态。

适用于（单不限于）如下场景：

升级服务时候，对所要升级的服务设置在升级的时间段不发送警报通知。
在服务迁移的时候，对涉及到的服务在迁移的时间段不发送警报通知。