基于标签的告警路由

在 Alertmanager 的配置中会定义一个基于标签匹配规则的告警路由树，以确定在接收到告警后 Alertmanager 需要如何对其进行处理：

  1. route: <route>

其中 route 中则主要定义了告警的路由匹配规则，以及 Alertmanager 需要将匹配到的告警发送给哪一个 receiver，一个最简单的route定义如下所示：

  1. route:
  2.   group_by: ['alertname']
  3.   receiver: 'web.hook'
  4. receivers:
  5. - name: 'web.hook'
  6.   webhook_configs:
  7.   - url: 'http://127.0.0.1:5001/'

如上所示：在 Alertmanager 配置文件中，我们只定义了一个路由，那就意味着所有由 Prometheus 产生的告警在发送到 Alertmanager 之后都会通过名为 web.hook 的 receiver 接收。这里的 web.hook 定义为一个 webhook 地址。当然实际场景下，告警处理可不是这么简单的一件事情，对于不同级别的告警，我们可能会不完全不同的处理方式，因此在route中，我们还可以定义更多的子Route，这些Route通过标签匹配告警的处理方式，route 的完整定义如下：

  1. [ receiver: <string> ]
  2. [ group_by: '[' <labelname>, ... ']' ]
  3. [ continue: <boolean> | default = false ]
  5. match:
  6.   [ <labelname>: <labelvalue>, ... ]
  8. match_re:
  9.   [ <labelname>: <regex>, ... ]
  11. [ group_wait: <duration> | default = 30s ]
  12. [ group_interval: <duration> | default = 5m ]
  13. [ repeat_interval: <duration> | default = 4h ]
  15. routes:
  16.   [ - <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. route:
  2.   receiver: 'default-receiver'
  3.   group_wait: 30s
  4.   group_interval: 5m
  5.   repeat_interval: 4h
  6.   group_by: [cluster, alertname]
  7.   routes:
  8.   - receiver: 'database-pager'
  9.     group_wait: 10s
  10.     match_re:
  11.       service: mysql|cassandra
  12.   - receiver: 'frontend-pager'
  13.     group_by: [product, environment]
  14.     match:
  15.       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) 中的哪一个应用程序出现了问题，可以快速对应用进行问题定位。