利用Prometheus 打造企业分布式监控平台(9)--最后的洼地Alertmanager

AlertManager用于处理客户端应用程序（如Prometheus）的警报。它还负责对警报进行重复数据删除，分组以及将其路由到其他收件人（例如电子邮件，Slack，Pager Duty）。

如上图所示，监控和报警紧密联系在一起。对于一个企业级监控平台，少不了讲报警这个领域。

Alertmanager特性

Alertmanager支持分组，抑制，静默等特性。

分组

分组将具有类似性质的警报归类为一个通知。这在较大的中断中特别有用，当大量系统一次出现故障并且成百上千的警报可能同时触发时。

示例：当发生网络分区时，群集中正在运行数十个或数百个服务实例，一半服务实例无法再访问数据库Prometheus中的警报规则配置为在每个服务实例无法发送警报时发送警报与数据库通信。结果，数百个警报被发送到Alertmanager。

作为用户，一个人只希望获得一个页面，同时仍然能够准确查看受影响的服务实例。因此，可以将Alertmanager配置为按其群集和警报名称对警报进行分组，从而发送一个紧凑的通知。

警报的分组，分组通知的时间以及这些通知的接收者由配置文件中的路由树配置。

抑制

抑制是一种概念，如果某些其他警报已经触发，则抑制某些警报的通知。

例如：警报正在触发，通知整个群集无法访问。如果警报特定，则警报管理器可以配置为使与该群集有关的所有其他警报静音。这可以防止与警报无关的成百上千个触发警报的通知。实际问题。

通过Alertmanager的配置文件配置抑制。

静默

静默是简单地将给定时间的警报静音的一种直接方法。静默是根据匹配器配置的，就像路由树一样。检查传入的警报是否匹配活动静默的所有相等或正则表达式匹配器 ，则不会针对该警报发送任何通知。

在Alertmanager的Web界面中配置沉默。当然也提供了api接口，做集成的时候，可以调用接口完成静默操作。

高可用方案

Alertmanager引入了Gossip机制。Gossip机制为多个Alertmanager之间提供了信息传递的机制。确保及时在多个Alertmanager分别接收到相同告警信息的情况下，也只有一个告警通知被发送给Receiver。

将几个不同的节点组成集群，然后server端配置文件写入集群里的所有节点，这样能够实现告警组件的高可用，这是prometheus官方的解决方案。

改进方案

Alertmanager虽然已经比较优秀了，但是在落地的过程中，存在以下问题：

• Alertmanager 支持许多通知方式，但是按照社区的想法，不会支持新增另外的通知方式了，因为很多alertmanager 版本受制于各种修复通知方式的bug。这也是in-tree架构的缺点。此外，国内的很多通讯产品，并没有被支持，比如钉钉和电话。当然为了扩展，社区支持了webhook的方式。
• 此外，一个完善的报警系统，势必要支持报警分析，针对过去时间维度的报警，做一些比如topK的分析，有助于指导运维方向。目前Alertmanager没有将历史报警做持久化处理。
• 缺失oncall。一般企业的报警系统是需要和oncall结合起来的。

所以真正在一个企业监控系统中落地，我们需要：

• Alertmanager 将所有的报警通过webhook的形式发送到消息通知系统。
• 消息通知系统支持众多通知类型，我们现在实现的是邮件，钉钉（工作群和个人通知），收集语音。该系统除了发送通知，还负责报警信息持久化。然后就可以定制相应的dashbord来做报警信息分析。例如：

• 结合我们的oncall系统，oncall 系统根据值班情况，发送指令给消息通知系统，实现报警发送给对应的oncall 人员。