Alertmanager 处理由 Prometheus 服务器等客户端应用程序发送的告警。负责对它们进行分组、静默、抑制、去重并路由到正确的接收方,例如Email、Wechat、Webhook。
![](http://img.zhengzen.com/upload/luyou2_baike2/luyou_809125269_1.jpg)
路由分组
在文章《》中我们介绍了告警(Alerts)进入Alertmanager后,首先进行路由匹配,本篇我们将详解如何实现灵活、可扩展的路由配置。
Alertmanager的路由设计比较新颖,借鉴了Kubernetes的label selector能力,并结合树形多层次深度优先匹配,实现了非常灵活和可扩展的路由,总结特点如下:
- 基于label匹配Alerts,解耦了告警规则与接收人
- 基于树形结构深度优先匹配,支持多层次灵活匹配
- 在支持深度优先匹配基础上,同时支持是否继续匹配兄弟节点路由
接下来,我们将探讨如何基于Alertmanger灵活强大的路由设计出适应组织的告警路由。
从一个小型团队开始,Alertmanager能提供很好的能力,只需要配置简单的业务转发逻辑就可以工作。例如基础告警转到oncall,业务告警转到业务负责部门。这些基本功能很好配置,不需要太多设计。
然而,在一个更大的组织中,事情并不是那么简单。可能有很多团队,每个团队都有自己的需求,希望将通知以不同的方式发送到不同的地方。一个组织通常会共享一组 Alertmanagers,因此首先要做的是在每个 Prometheus 的规则上建立一些标准标签,例如service或team作为external_label以标识告警对应哪个团队或者服务。
根路由
Alertmanger支持树形路由,首先我们需要设置一个根路由(root route),以接收所有Alerts,并作为默认的路由。
需要确保根路由有一个合理的receiver,以便在未得到其他路由匹配时也可以及时处理。
子路由
在根路由下面,每个团队都有一条路由,使用team标签来匹配每个团队的警报。然后,每个团队的Alerts都会路由到对应的团队路由下,不会影响其他团队。然后,每个团队都可以拥有子路由,例如,将非生产环境的Alerts发送到oncall,其他Alerts根据业务不同发给不同的开发同学。随着时间的推移,可能会有更多的路线来覆盖服务中的细微之处,例如应用不同的通知group_by或group_interval某些通知。
对于给定的组织或者团队,虽然警报规则可能会经常更改,但Alertmanager的配置应该很少更改,通常最多每隔几个月更改一次。因此,将所有内容保存在一个大文件中,可以通过git和Pull Rrequest向运行警报管理器的监控团队完成任何更改申请,有点类似gitops的感觉。
可以在源代码控制中为每个团队提供一个YAML文件,他们可以使用他们的路由和接收器进行编辑,然后自动将它们整合在一起。同时要进行必要格式和逻辑检查以防止破坏,可以借助 Alertmanager的工具实现解析和check配置。
需要注意的事情是,抑制规则目前是全局性的,如果没有设计很好的labels方案,很难利用好抑制规则。
多路由匹配
Alertmanger支持匹配多条路由,可以在路由的每个节点开启或者关闭,利用该特性,这可以支持特定的组织范围的路由,只需要将该路由放到其他其他子路由前面,并开启继续匹配后续兄弟节点路由的开关即可。
例如,一些组织喜欢通过webhook记录所有Alerts,并且不影响继续路由到各个团队,就可以利用该特性实现。
总结一下
![](http://img.zhengzen.com/upload/luyou2_baike2/luyou_809125270_2.jpg)
根路由作为默认路由
每个团队新建团队范围的路由,隔离不同团队的Alerts
然后在各个团队内,可以根据需要再细化出更多的路由
关键词:如何规划告警路由(路由器告警)