鲁达 Alertmanager 处理由 Prometheus 服务器等客户端应用程序发送的告警。负责对它们进行分组、静默、抑制、去重并路由到正确的接收方，例如Email、Wechat、Webhook。
路由分组
在文章《》中我们介绍了告警（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，并且不影响继续路由到各个团队，就可以利用该特性实现。
总结一下
根路由作为默认路由
每个团队新建团队范围的路由，隔离不同团队的Alerts
然后在各个团队内，可以根据需要再细化出更多的路由