路由器报警(路由器显示告警什么意思)
alertmanager处理客户端应用程序(如Prometheus server)发送的警报。负责对它们进行分组、消音、抑制、去重并路由到正确的收件人，如Email、微信、Webhook。
路由数据包
在文章“”中，我们介绍了在警报进入alertmanager后，应该首先路由它们。在本文中，我们将详细说明如何实现灵活和可扩展的路由配置。
alertmanager的路由设计相当新颖，它借鉴了Kubernetes的标签选择器能力，结合树状多级深度优先匹配，实现了非常灵活、可扩展的路由。概括特征如下:
接下来，我们将讨论如何基于alertmanger灵活而强大的路由来设计适应组织的警报路由。
从一个小团队开始，alertmanager可以提供很好的能力，只需要配置简单的业务转发逻辑就可以工作。比如基础告警转oncall，业务告警转业务责任部门。这些基本功能配置良好，不需要太多设计。
然而，在一个更大的组织中，事情并不那么简单。可能有很多团队，每个团队都有自己的需求，希望用不同的方式把通知送到不同的地方。一个组织通常共享一组alertmanagers，所以首先要做的是在每个Prometheus规则上建立一些标准标签，比如service或team作为external_label，以标识警报对应于哪个团队或服务。
根警报管理器支持树路由。首先，我们需要设置一条根路由来接收所有警报，并将其用作默认路由。
需要确保根路由有一个合理的接收方，以便在没有其他路由匹配的情况下能够及时处理。
子路由在根路由下，每个团队都有一个路由。使用团队标签来匹配每个团队的警报。然后每个队伍的告警都会被路由到对应的队伍路由，不会影响到其他队伍。然后每个团队可以有子路线，比如把非生产环境的告警发送给oncall，根据不同的业务把其他的告警发送给不同的开发同学。随着时间的推移，可能会有更多的途径来覆盖服务中的细微之处，例如应用不同的通知group_by或group_interval某些通知。
对于给定的组织或团队，尽管警报规则可能会频繁更改，但alertmanager的配置应该很少更改，通常最多每几个月更改一次。所以所有的内容都保存在一个大文件中，任何变更申请都可以通过git和Pull Rrequest完成给运行报警管理器的监控团队，有点类似于gitops的感觉。
您可以在源代码控制中为每个团队提供一个YAML文件，他们可以使用他们的路线和接收者来编辑它，然后自动将它们集成在一起。同时要做必要的格式和逻辑检查防止损坏，可以使用alertmanager的工具实现解析和检查配置。
需要注意的是，抑制规则目前是全局的，没有一个设计良好的标签方案，很难很好地利用抑制规则。
多路由匹配报警管理器支持匹配多条路由，可以在路由的每个节点打开或关闭。通过使用此功能，这可以支持特定的组织范围的路由，只需将此路由放在其他子路由的前面，并打开开关以继续匹配后续的兄弟路由。
比如有些组织喜欢通过webhook记录所有的预警，在不影响持续路由到各个团队的情况下，通过这个特性就可以实现。
总结
根路由作为默认路由。
每个团队创建一个新的团队范围的路由来隔离来自不同团队的警报。
然后，在每个团队内部，可以根据需要细化更多路线。