Prometheus的本地存儲給Prometheus帶來了簡單高效的使用體驗，可以讓Promthues在單節點的情況下滿足大部分用戶的監控需求。但是本地存儲也同時限制了Prometheus的可擴展性，帶來了數據持久化等一系列的問題。通過Prometheus的Remote Storage特性可以解決這一系列問題，包括Promthues的動態擴展，以及歷史數據的存儲。
而除了數據持久化問題以外，影響Promthues性能表現的另外一個重要因素就是數據采集任務量，以及單台Promthues能夠處理的時間序列數。因此當監控規模大到Promthues單台無法有效處理的情況下，可以選擇利用Promthues的聯邦集群的特性，將Promthues的監控任務划分到不同的實例當中。
基本HA：服務可用性
由於Promthues的Pull機制的設計，為了確保Promthues服務的可用性，用戶只需要部署多套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負責采集基礎設施相關的監控指標，另外一個Prometheus Server負責采集應用監控指標。再有上層Prometheus Server實現對數據的匯聚。
場景二：多數據中心
這種模式也適合與多數據中心的情況，當Promthues Server無法直接與數據中心中的Exporter進行通訊時，在每一個數據中部署一個單獨的Promthues Server負責當前數據中心的采集任務是一個不錯的方式。這樣可以避免用戶進行大量的網絡配置，只需要確保主Promthues Server實例能夠與當前數據中心的Prometheus Server通訊即可。 中心Promthues Server負責實現對多數據中心數據的聚合。
按照實例進行功能分區
這時在考慮另外一種極端情況，即單個采集任務的Target數也變得非常巨大。這時簡單通過聯邦集群進行功能分區，Prometheus Server也無法有效處理時。這種情況只能考慮繼續在實例級別進行功能划分。
如上圖所示，將統一任務的不同實例的監控數據采集任務划分到不同的Prometheus實例。通過relabel設置，我們可以確保當前Prometheus Server只收集當前采集任務的一部分實例的監控指標。
global:
external_labels:
slave: 1 # This is the 2nd slave. This prevents clashes between slaves.
scrape_configs:
- job_name: some_job
relabel_configs:
- source_labels: [__address__]
modulus: 4
target_label: __tmp_hash
action: hashmod
- source_labels: [__tmp_hash]
regex: ^1$
action: keep
並且通過當前數據中心的一個中心Prometheus Server將監控數據進行聚合到任務級別。
- scrape_config:
- job_name: slaves
honor_labels: true
metrics_path: /federate
params:
match[]:
- '{__name__=~"^slave:.*"}' # Request all slave-level time series
static_configs:
- targets:
- slave0:9090
- slave1:9090
- slave3:9090
- slave4:9090
高可用方案選擇
上面的部分，根據不同的場景演示了3種不同的高可用部署方案。當然對於Promthues部署方案需要用戶根據監控規模以及自身的需求進行動態調整，下表展示了Promthues和高可用有關3個選項各自解決的問題，用戶可以根據自己的需求靈活選擇。
| 選項\需求 | 服務可用性 | 數據持久化 | 水平擴展 |
|---|---|---|---|
| 主備HA | v | x | x |
| 遠程存儲 | x | v | x |
| 聯邦集群 | x | x | v |