前言
在Prometheus設計上，使用本地存儲可以降低Prometheus部署和管理的複雜度同時減少高可用（HA）帶來的複雜性。 在默認情況下，用戶只需要部署多套Prometheus，採集相同的Targets即可實現基本的HA。
當然本地存儲也帶來了一些不好的地方，首先就是數據持久化的問題，特別是在像Kubernetes這樣的動態集羣環境下，如果Promthues的實例被重新調度，那所有歷史監控數據都會丟失。 其次本地存儲也意味着Prometheus不適合保存大量歷史數據(一般Prometheus推薦只保留幾周或者幾個月的數據)。最後本地存儲也導致Prometheus無法進行彈性擴展。爲了適應這方面的需求，Prometheus提供了remote_write和remote_read的特性，支持將數據存儲到遠端和從遠端讀取數據。通過將監控樣本採集和數據存儲分離，解決Prometheus的持久化問題。
除了本地存儲方面的問題，由於Prometheus基於Pull模型，當有大量的Target需要採樣本時，單一Prometheus實例在數據抓取時可能會出現一些性能問題，聯邦集羣的特性可以讓Prometheus將樣本採集任務劃分到不同的Prometheus實例中，並且通過一個統一的中心節點進行聚合，從而可以使Prometheuse可以根據規模進行擴展。
遠程存儲
Prometheus的本地存儲設計可以減少其自身運維和管理的複雜度，同時能夠滿足大部分用戶監控規模的需求。但是本地存儲也意味着Prometheus無法持久化數據，無法存儲大量歷史數據，同時也無法靈活擴展和遷移。
爲了保持Prometheus的簡單性，Prometheus並沒有嘗試在自身中解決以上問題，而是通過定義兩個標準接口(remote_write/remote_read)，讓用戶可以基於這兩個接口將數據保存到任意第三方的存儲服務中，這種方式在Promthues中稱爲遠程存儲（Remote Storage）。
Remote Write
用戶可以在Prometheus配置文件中指定Remote Write(遠程寫)的URL地址，比如指向influxdb中，也可指向消息隊列等。
Remote Read
Promthues的Remote Read(遠程讀)的流程當中，當用戶發起查詢請求後（也就是說Remote Read只在數據查詢時有效），Promthues將向remote_read中配置的URL發起查詢請求，接收Promthues的原始樣本數據。
當獲取到樣本數據後，Promthues在本地使用PromQL對樣本數據進行二次處理。
聯邦
對於大部分監控規模而言，我們只需要在每一個數據中心(例如一個Kubernetes集羣)安裝一個Prometheus Server實例，就可以在各個數據中心處理上千規模的集羣，這也可以避免網絡配置的複雜性。
如上圖所示，在每個數據中心部署單獨的Prometheus Server，用於採集當前數據中心監控數據。並由一箇中心的Prometheus Server負責聚合多個數據中心的監控數據。這一特性在Promthues中稱爲聯邦集羣。
聯邦集羣的核心在於每一個Prometheus Server都包含一個用於獲取當前實例中監控樣本的接口/federate。對於中心Prometheus Server而言，無論是從其他的Prometheus實例還是Exporter實例中獲取數據實際上並沒有任何差異。
scrape_configs:
- job_name: 'federate'
scrape_interval: 15s
honor_labels: true
metrics_path: '/federate'
params:
'match[]':
- '{job="prometheus"}'
- '{__name__=~"job:.*"}'
- '{__name__=~"node.*"}'
static_configs:
- targets:
- '192.168.77.11:9090'
- '192.168.77.12:9090'
通過URL中的match[]參數指定我們可以指定需要獲取的時間序列。
honor_labels配置true可以確保當採集到的監控指標衝突時，能夠自動忽略衝突的監控數據。如果爲false時，prometheus會自動將衝突的標籤替換爲exported_的形式。
功能分區
功能分區，即通過聯邦集羣的特性在任務級別對Prometheus採集任務進行劃分，以支持規模的擴展。
例如如下所示，可以在各個數據中心中部署多個Prometheus Server實例。每一個Prometheus Server實例只負責採集當前數據中心中的一部分任務(Job)，再通過中心Prometheus實例進行聚合。
幾種高可用方案
遠程存儲解決了prometheus數據持久化和可擴展性的問題，聯邦解決了單臺prometheus數據採集任務量過大的問題。它們的組合可以作爲高可用方案。
基本HA：服務可用性
此方案用戶只需要部署多套Prometheus Server實例，並且採集相同的Exporter目標即可。
基本的HA模式只能確保Promthues服務的可用性問題，但是不解決Prometheus Server之間的數據一致性問題以及持久化問題(數據丟失後無法恢復)，也無法進行動態的擴展。因此這種部署方式適合監控規模不大，Promthues Server也不會頻繁發生遷移的情況，並且只需要保存短週期監控數據的場景。
基本HA + 遠程存儲
在基本HA模式的基礎上通過添加Remote Storage存儲支持，將監控數據保存在第三方存儲服務上。
在保證Promthues服務可用性的基礎上，同時確保了數據的持久化，當Promthues Server發生宕機或者數據丟失的情況下，可以快速的恢復。 同時Promthues Server可能很好的進行遷移。因此，該方案適用於用戶監控規模不大，但是希望能夠將監控數據持久化，同時能夠確保Promthues Server的可遷移性的場景。
基本HA + 遠程存儲 + 聯邦集羣
當單臺Promthues Server無法處理大量的採集任務時，用戶可以考慮基於Prometheus聯邦集羣的方式將監控採集任務劃分到不同的Promthues實例當中，即在任務級別進行功能分區。
這種方案適用於兩種場景：
場景一：單數據中心 + 大量的採集任務
這種場景下Promthues的性能瓶頸主要在於大量的採集任務，因此用戶需要利用Prometheus聯邦集羣的特性，將不同類型的採集任務劃分到不同的Promthues子服務中，從而實現功能分區。
場景二：多數據中心
這種模式也適合與多數據中心的情況，當Promthues Server無法直接與數據中心中的Exporter進行通訊時，在每一個數據中部署一個單獨的Promthues Server負責當前數據中心的採集任務是一個不錯的方式。這樣可以避免用戶進行大量的網絡配置，只需要確保主Promthues Server實例能夠與當前數據中心的Prometheus Server通訊即可。 中心Promthues Server負責實現對多數據中心數據的聚合。
Alertmanager高可用
在prometheus server高可用的情況下，單個alertmanager容易引發單點故障。
解決該問題最直接的方式，就是部署多套Alertmanager。但是由於Alertmanager之間不存在並不瞭解彼此的存在，因此則會出現告警通知被不同的Alertmanager重複發送多次的問題。
爲了解決這一問題，Alertmanager引入了Gossip機制，保證多個Alertmanager之間的信息傳遞。確保在多個Alertmanager分別接收到相同告警信息的情況下，也只有一個告警通知被髮送給Receiver。
Gossip協議
Gossip是分佈式系統中被廣泛使用的協議，用於實現分佈式節點之間的信息交換和狀態同步。如下所示，當Alertmanager接收到來自Prometheus的告警消息後，會按照以下流程對告警進行處理：
- 在第一個階段Silence中，Alertmanager會判斷當前通知是否匹配到任何的靜默規則，如果沒有則進入下一個階段，否則則中斷流水線不發送通知。
- 在第二個階段Wait中，Alertmanager會根據當前Alertmanager在集羣中所在的順序(index)等待index * 5s的時間。
- 當前Alertmanager等待階段結束後，Dedup階段則會判斷當前Alertmanager數據庫中該通知是否已經發送，如果已經發送則中斷流水線，不發送告警，否則則進入下一階段Send對外發送告警通知。
- 告警發送完成後該Alertmanager進入最後一個階段Gossip，Gossip會通知其他Alertmanager實例當前告警已經發送。其他實例接收到Gossip消息後，則會在自己的數據庫中保存該通知已發送的記錄。
因此如下所示，Gossip機制的關鍵在於兩點：
- Silence設置同步：Alertmanager啓動階段基於Pull-based從集羣其它節點同步Silence狀態，當有新的Silence產生時使用Push-based方式在集羣中傳播Gossip信息。
- 通知發送狀態同步：告警通知發送完成後，基於Push-based同步告警發送狀態。Wait階段可以確保集羣狀態一致。
Alertmanager基於Gossip實現的集羣機制雖然不能保證所有實例上的數據時刻保持一致，但是實現了CAP理論中的AP系統，即可用性和分區容錯性。同時對於Prometheus Server而言保持了配置了簡單性，Promthues Server之間不需要任何的狀態同步。
gossip集羣搭建
多個Alertmanager可以組成gossip集羣，需要在Alertmanager啓動時設置相應的參數。其中主要的參數包括：
--cluster.listen-address: 當前alertmanager在gossip集羣的監聽地址【這地址指的是啥沒太懂，如有錯誤還望指點】--cluster.peer: 需要關聯的gossip集羣的監聽地址
舉個例子：
./alertmanager --web.listen-address=":9093" --cluster.listen-address="127.0.0.1:8001" --storage.path=/tmp/data01 --config.file=/etc/prometheus/alertmanager01.yml --log.level=debug
./alertmanager --web.listen-address=":9094" --cluster.listen-address="127.0.0.1:8002" --cluster.peer=127.0.0.1:8001 --storage.path=/tmp/data02 --config.file=/etc/prometheus/alertmanager02.yml --log.level=debug
./alertmanager --web.listen-address=":9095" --cluster.listen-address="127.0.0.1:8003" --cluster.peer=127.0.0.1:8001 --storage.path=/tmp/data03 --config.file=/etc/prometheus/alertmanager03.yml --log.level=debug
該例子創建了三個alertmanager組成gossip集羣，後兩個創建的alertmanager需要關聯第一個創建alertmanager對應的gossip監聽地址。
啓動完成後訪問任意Alertmanager節點http://localhost:9093/#/status,可以查看當前Alertmanager集羣的狀態。
對應的prometheus配置文件中的告警部分需要添加多個alertmanager地址：
alerting:
alertmanagers:
- static_configs:
- targets:
- 127.0.0.1:9093
- 127.0.0.1:9094
- 127.0.0.1:9095