前面的系列中， 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部署不易
------------------------------------------------------------------------------------------------------------------- 未完待續--------------------------------------------------------------------------------------------------------------