前面的系列中， prometheus和alertmanager都是單機部署的，會有單機宕機導致系統不可用情況發生。本文主要介紹下prometheus和alertmanager的高可用方案。

服務的高可靠性架構（基本ha）

promehtues是以pull方式進行設計的，因此手機時序資料都是通過prometheus本身主動發起的，而為了保證prometheus服務能夠正常執行，只需要建立多個prometheus節點來收集同樣的metrics即可。

架構圖：

這個架構可以保證服務的高可靠性，但是並不能解決多個prometheus例項之間的資料一致性問題，也無法資料進行長期儲存，且單一例項無法負荷的時候，將延伸出效能瓶頸問題，因此這種架構適合小規模進行監控。
優點：

• 服務能夠提供基本的可靠性
• 適合小規模監控，只需要短期儲存。

缺點：

• 無法擴充套件
• 資料有不一致問題
• 無法長時間保持
• 當承載量過大時，單一prometheus無法負荷。

服務高可靠性結合遠端儲存（基本ha + remote storage）
這種架構是在基本ha的基礎上面，加入遠端儲存的，將資料儲存在第三方的儲存系統中。

該架構解決了資料永續性問題， 當prometheus server發生故障、重啟的時候可以快速恢復資料，同時prometheus可以很好的進行遷移，但是這也只適合小規模的監測使用。

優點：

• 服務能夠提供可靠性
• 適合小規模監測
• 資料能夠持久化儲存
• prometheus可以靈活遷移
• 能夠得到資料還原

缺點：

• 不適合大規模監控
• 當承載量過大時，單一prometheus server無法負荷

服務高可靠性結合遠端儲存和聯邦（基本ha + remote storage + federation）

這種架構主要是解決單一 prometheus server無法處理大量資料收集的問題，而且加強了prometheus的擴充套件性，通過將不同手機任務分割到不同的prometheus實力上去。

該架構通常有2種使用場景：

單一資料中心，但是有大量收集任務，這種場景行prometheus server 可能會發生效能上的瓶頸，主要是單一prometheus server 要承載大量資料書籍任務， 這個時候通過federation來將不同型別的任務分到不同的prometheus 子server 上， 再有上層完成資料聚合。

多資料中心， 在多資料中心下，這種架構也能夠使用，當不同資料中心的exporter無法讓最上層的prometheus 去拉取資料是， 就能通過federation來進行分層處理， 在每個資料中心建立一組收集該資料中心的prometheus server ， 在由上層的prometheus 來進行抓取， 並且也能夠依據每個收集任務的承載量來部署分級，但是需要確保上下層的prometheus server 是互通的。

優點

• 服務能夠提供可靠性
• 資料能夠被永續性保持在第三方儲存系統中
• promethues server 能夠遷移
• 能夠得到資料還原
• 能夠依據不同任務進行層級劃分
• 適合不同規模監控
• 能夠很好的擴充套件

缺點

• 部署架構負載
• 維護困難性增加
• 在kubernetes部署不易