【1】alertmanager集群高可用介绍
（1.1）基本介绍
为了提升Promthues的服务可用性，通常用户会部署两个或者两个以上的Promthus Server，它们具有完全相同的配置包括Job配置，以及告警配置等。当某一个Prometheus Server发生故障后可以确保Promthues持续可用。
同时基于Alertmanager的告警分组机制即使不同的Prometheus Sever分别发送相同的告警给Alertmanager，Alertmanager也可以自动将这些告警合并为一个通知向receiver发送。
但不幸的是，虽然Alertmanager能够同时处理多个相同的Prometheus Server所产生的告警。但是由于单个Alertmanager的存在，当前的部署结构存在明显的单点故障风险，当Alertmanager单点失效后，告警的后续所有业务全部失效。
如下所示，最直接的方式，就是尝试部署多套Alertmanager。但是由于Alertmanager之间不存在并不了解彼此的存在，因此则会出现告警通知被不同的Alertmanager重复发送多次的问题。
日常部署 alertmanager 组件的时候，都是用的单点架构，架构图如下所示：
那么显然这样是存在单点故障的，另外对运维而言，其实单点故障是很可怕的，收不到报警有时候是致命的，所以要用高可用的报警方式：
alertmanager的高可用方式有两种方法：
第一种就是引入负载均衡，通过负载均衡的方法保证服务可用，架构如下：
这种方式可以实现高可用 并且可以灵活扩展，云服务的话一般都有负载均衡。
今天主要介绍官方提供的集群方法，架构如下：
Alertmanager引入了Gossip机制。Gossip机制为多个Alertmanager之间提供了信息传递的机制。
确保及时在多个Alertmanager分别接收到相同告警信息的情况下，也只有一个告警通知被发送给Receiver。
（1.2）Gossip机制
要知道什么是Gossip机制，必须了解清楚Alertmanager中的每一次警报通知是如何产生的，下面一图很详细的阐述了警报个流程：
Gossip俩个关键：
-
Alertmanager 节点之间的Silence设置相同，这样确保了设置为静默的警报都不会对外发送
-
Alertmanager 节点之间通过Gossip机制同步警报通知状态，并且在流程中标记Wait阶段，保证警报是依次被集群中的Alertmanager节点读取并处理
一般来说Gossip有两种实现方式分别为Push-based和Pull-based。
Push-based：当集群中某一节点A完成一个工作后，随机的从其它节点B并向其发送相应的消息，节点B接收到消息后在重复完成相同的工作，直到传播到集群中的所有节点。
Pull-based：节点A会随机的向节点B发起询问是否有新的状态需要同步，如果有则返回。
在简单了解了Gossip协议之后，我们来看Alertmanager是如何基于Gossip协议实现集群高可用的。如下所示，当Alertmanager接收到来自Prometheus的告警消息后，会按照以下流程对告警进行处理：
-
在第一个阶段Silence中，Alertmanager会判断当前通知是否匹配到任何的静默规则，如果没有则进入下一个阶段，否则则中断流水线不发送通知。
-
在第二个阶段Wait中，Alertmanager会根据当前Alertmanager在集群中所在的顺序(index)等待index * 5s的时间。
-
当前Alertmanager等待阶段结束后，Dedup阶段则会判断当前Alertmanager数据库中该通知是否已经发送，如果已经发送则中断流水线，不发送告警，否则则进入下一阶段Send对外发送告警通知。
-
告警发送完成后该Alertmanager进入最后一个阶段Gossip，Gossip会通知其他Alertmanager实例当前告警已经发送。其他实例接收到Gossip消息后，则会在自己的数据库中保存该通知已发送的记录。
【2】alertmanager 集群配置
（2.1）alertmanager集群参数
# 当前实例集群服务监听地址，为空则禁用高可用功能 --cluster.listen-address="0.0.0.0:9094" # 表示集群节点对其他节点发布的地址，其他节点可以用这个地址与该地址通信 --cluster.advertise-address=CLUSTER.ADVERTISE-ADDRESS # 用来设置该 Alertmanager 节点的集群对等体，将告警数据同步其他节点 --cluster.peer=CLUSTER.PEER # 对等超时时间，默认15秒 --cluster.peer-timeout=15s # 集群消息传播时间，默认200ms --cluster.gossip-interval=200ms # 定义了多个 Alertmanager 实例之间的信息同步频率 --cluster.pushpull-interval=10ms # 评估通知之前等待集群连接建立的最长时间 --cluster.tcp-timeout=10s # 在标记节点不正常之前等待确认的时间 --cluster.probe-timeout=500ms # 随机节点探测之间的间隔 --cluster.probe-interval=1s # 用来设置集群状态稳定的超时时间的参数 --cluster.settle-timeout=10ms # 尝试重新连接到丢失的对等设备之间的间隔时间 --cluster.reconnect-interval=10s # 尝试重新连接到丢失的对等设备的间隔时间 --cluster.reconnect-timeout=6h0m0s # 用于在 Alertmanager 集群模式中配置 TLS 证书 --cluster.tls-config="" # 允许节点发送不加密的广播请求，从而允许其他节点发现它的地址。 # 这条最好不用 --cluster.allow-insecure-public-advertise-address-discovery