基于Gossip流言算法实现alertmanager高可用

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　作者：尹正杰

版权声明：原创作品，谢绝转载！否则将追究法律责任。

目录

• 一.alertmanager高可用架构设计
  • 1 Gossip流言算法协议原理分析
  • 2 Gossip的优劣势
  • 3 Gossip中通信模式
• 二.搭建alertmanager高可用架构实战
  • 1.搭建alertmanager高可用架构
  • 2..测试高可用

一.alertmanager高可用架构设计

1 Gossip流言算法协议原理分析

如上图所示，我们可以发现alertmanager存在单点的故障，这一点官方也考虑到了，因此采用了gossip实现alertmanager集群模式。

gossip流言算法协议原理分析:
	- 1.前提设定: Gossip时周期性的散播消息，把周期限定为1秒;
	- 2.被感染节点随机选择K个临近节点(fan-out)散播消息，这里把fan-out设置为3，每次最多往3个节点散播;
	- 3.每次散播消息都选择尚未发送过的节点进行散播;
	- 4.收到消息的节点不再往发送节点散播，比如A发送给B，那么B进行散播的时候，不在发送A;
	- 5.Gossip过程是异步的，这就是说发消息的节点不会关注对方是否收到，即不等待响应，不管对方有没有收到，它都会每隔1秒向周围节点发消息，异步是它的优点，而消息冗余是它的弱点;

2 Gossip的优劣势

优点:
	- 扩展性:
		网络可以允许节点的任意增加和减少，新增加的节点状态最终会与其他节点一致。
	
	- 容错:
		网络中任何节点的宕机和重启都不会影响Gossip消息的传播，Gossip协议具有天然的分布式系统容错特性。

	- 去中心化:
		Gossip协议不要求任何中心节点，所有节点都可以是对等的，任何一个节点无需知道整个网络状况，只要网络是连通的。
		换句话说，任意一个节点就可以把消息散播到全网。
		
	- 一致性收敛:
		Gossip协议中的消息会以一传十，十传百一样的指数速级速度在网络中快速传播，因此系统状态不一致可以在很快的时间内收敛到一致。
		换句话说，消息传播速度达到了logN。
		
	- 简单:
		Gossip协议的过程及其简单，实现起来几乎没有太多复杂性。
		
		
缺点:
	分布式网络中，没有一种完美的解决方案，Gossip协议和其他协议一样，也有一些不可避免的缺陷，主要有是在数据延迟和冗余。
	
	- 消息的延迟:
		由于Gossip协议中，节点指挥随机向少数几个节点发送消息，消息最终是通过多个轮次的散播而到达全网的。
		因此使用Gossip协议会造成不可避免的消息延迟，不适合用在实时性要求较高的场景下。
		
	- 消息冗余:
		Gossip协议规定，节点会定期随机选择周围节点发送消息，而收到消息的节点也会重复该步骤，因此就不可避免存在消息重复发送给同一节点的情况。
		造成了消息的冗余，同时也增加收到消息的节点处理的压力，而且由于定期发送，即使收到了消息的节点还会反复收到重复消息，加重了消息的冗余。
	
	

3 Gossip中通信模式

如上图所示，gossip底层库的热度还是蛮火的:
	https://github.com/hashicorp/memberlist

在Gossip协议下，网络中两个节点之间有三种通信模式: "PUSH","PULL"和"PUSH/PULL"。
    - PUSH:
        节点A将数据(key,value,version)及对应的版本号推送给B节点，B节点更新A中比自己新的数据。

    - PULL:
        A仅将数据key,vaerion推送给B，B将本地比A新的数据Key，value，version推送给A，A更新本地。

    - PUSH/PULL:
        与PULL类似，只是多了一步，A再将本地比B新的数据推送给B,B则更新本地。
	
如果把两个节点数据同步一次定义为一个周期，则在一个周期内，PUSH需通信1次，PULL需通信2次，PULL/PUSH则需要三次。

虽然消息数增加了，但从效果来讲，PUSH/PULL最好，理论上一个周期可以使两个节点完全一致，直观上PUSH/PULL的收敛速度也是最快的。

二.搭建alertmanager高可用架构实战

1.搭建alertmanager高可用架构

	1.一个节点("10.0.0.31")正常启动alertmanger
略，此过程参考之前的笔记。

[root@prometheus-server31 ~]# ss -ntl | egrep "9093|9094"
LISTEN 0      4096               *:9093             *:*          
LISTEN 0      4096               *:9094             *:*          
[root@prometheus-server31 ~]# 



	2.另外一个节点("10.0.0.42")启动alertmanger时需要使用"--cluster.peer"参数指定已经存在的alertmanager地址
[root@node-exporter42 alertmanager-0.27.0.linux-amd64]# ./alertmanager --cluster.peer=10.0.0.31:9094

2..测试高可用

测试gossip方法1:
	- 在一个10.0.0.31节点创建静默;
	- 在10.0.0.42页面上能看到静默的记录;
	
测试gossip方法2:
	- 将两个alertmanaager配置一致，提前将alertmanager的webhook配置为无法访问的地址;
	- 分别向两个alertmanager发送告警，分别查看两个alertmanager的日志发现仅有一个alertmanager触发报警超时的日志信息;


参考链接:
  https://www.cnblogs.com/yinzhengjie/p/18540986#2-发送消息到alertmanager
  https://www.cnblogs.com/yinzhengjie/p/18542942#二alertmanager实现告警静默silence