Prometheus监控神器-Alertmanager篇(4)

本章节主要讲解Alertmanager高可用的搭建与配置的详细的知识内容。

为了提升Prometheus的服务可靠性，我们会部署两个或多个的Prometheus服务，两个Prometheus具有相同的配置（Job配、告警规则、等），当其中一个Down掉了以后，可以保证Prometheus持续可用。

AlertManager自带警报分组机制，即使不同的Prometheus分别发送相同的警报给Alertmanager，Alertmanager也会自动把这些警报合并处理。

去重	分组	路由
Daduplicates	Groups	Route
将相同的警报合并成一个	根据定义的分组	经过路由分发给指定的receiver

虽然Alertmanager 能够同时处理多个相同的Prometheus的产生的警报，如果部署的Alertmanager是单节点，那就存在明显的的单点故障风险，当Alertmanager节点down机以后，警报功能则不可用。

解决这个问题的方法就是使用传统的HA架构模式，部署Alertmanager多节点。但是由于Alertmanager之间关联存在不能满足HA的需求，因此会导致警报通知被Alertmanager重复发送多次的问题。

Alertmanager为了解决这个问题，引入了Gossip机制，为多个Alertmanager之间提供信息传递机制。确保及时的在多个Alertmanager分别接受到相同的警报信息的情况下，不会发送重复的警报信息给Receiver.

Gossip 机制

要知道什么是Gossip机制，必须了解清楚Alertmanager中的每一次警报通知是如何产生的，下面一图很详细的阐述了警报个流程：

阶段	描述
Silence	在这个阶段中Alertmanager会判断当前通知是否匹配任何静默规则；如果没有则进入下一个阶段，否则会中断流程不发送通知。
Wait	Alertmanager 会根据当前集群中所处在的顺序[index]，等待 index * 5s 的时间。
Dedup	当等待结束完成，进入 Dedup 阶段，这时会判断当前Alertmanager TSDB中警报是否已经发送，如果发送则中断流程，不发送警报。
Send	如果上面的未发送，则进入 Send 阶段，发送警报通知。
Gossip	警报发送成功以后，进入最后一个阶段