基於Gossip流言演算法實現alertmanager高可用

尹正杰發表於2024-11-15
Go演算法

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　作者：尹正傑

版權宣告：原創作品，謝絕轉載！否則將追究法律責任。

目錄
  • 一.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

相關文章