高可用方案

基本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負責實現對多數據中心數據的聚合。

舉例說明：

我們要監控mysqld的運行狀態，可以使用1個主Prometheus+2個分片Prometheus(一個用來采集node_exporter的metrics、一個用來采集mysql_exporter的metrics)，然后在主Prometheus上做匯總

三台機器：

node1： prometheus2.0 （主）

node2：prometheus2.0 （采集node_exporter的metrics）

node3： prometheus2.0 （采集mysql_exporter的metrics）

 

node1: 

修改prometheus.yml

scrape_configs:
- job_name: 'federate'
   scrape_interval: 15s
   honor_labels: true
   metrics_path: '/federate'
   params:
     'match[]':
      - '{job=~"prometheus.*"}'
      - '{job="mysql"}'
   static_configs:
     - targets:
       - 'node2:9091'
       - 'node3:9092'

node2: 

修改prometheus.yml

scrape_configs:

- job_name: 'prometheus25'

   static_configs:
   - targets: ['node2:9090']
- job_name: 'prometheus26'
   static_configs:
   - targets: ['node3:9090']

node3: 

修改prometheus.yml

scrape_configs:

- job_name: 'mysqld'
   static_configs:
   - targets: ['node1:8089'] 

或者：

  file_sd_configs:

   - files: ['./mysqld.json']

cat mysqld.json
[
{
"targets": [
"node2:9104",
"node3:9104",
......
],
"labels": {
"services": "mysql_test",
}
}
]