在我們的監控的過程中，單個的Prometheus Server可以輕鬆的處理百萬的時間序列，但是問題來了，要是這個機器的規模大了呢，這不就完蛋了嗎。所以呢，這時候就要用到 Prometheus 的分區功能，在Prometheus裏面稱爲
Federation,方便我們進行擴展。
前言說明
前面在摘要裏面講到了Prometheus在大規模集羣裏面的不足之處。比如說 k8s 集羣環境下，現在的node 節點有 400 個，採集到的 樣本數（samples） 數是在200W+，在Prometheus官方顯示的是採集的速度是在 10w/sec ,現在集羣擴大，2w 個節點，怎麼去監控呢？我們要拿到pod 的運行狀態，但是單個的Prometheus 肯定是不足以滿足我們的實際需求的，現在這個Prometheus的分區的功能就能用到了，也就是要對其進行分區。
Federatioin
那我們現在來看看這個Federation(聯邦)功能的一個實現的過程。先看一個圖瞭解下什麼是 Federation:
看這個大家應該就比較清楚了。這相當於是一個master帶了三個小弟，這就是Prometheus的分區功能。也就是說，Prometheus可以採集另一個Prometheus的mstric，這樣的話，就可以對Prometheus進行分類型採集，最後由一個 Prometheus 進行歸總。
Hierarchical federation（分層聯盟）
分層聯合使Prometheus可以擴展到具有數十個數據中心和數百萬個節點的環境。在此用例中，聯合拓撲類似於一棵樹，更高級別的Prometheus服務器從大量從屬服務器收集聚合的時間序列數據。
Cross-service federation（跨服務聯邦）
在跨服務聯邦中，一個服務的 Prometheus 服務器被配置來提取來自其他服務的 Prometheus 服務器的指定的數據，以便在一個 Prometheus 服務器中對兩個數據集啓用告警和查詢。
官方提供了一個例子:
運行多個服務的羣集調度程序可能會公開有關在羣集上運行的服務實例的資源使用情況信息（例如內存和CPU使用情況）。另一方面，在該羣集上運行的服務將僅公開特定於應用程序的服務指標。通常，這兩組指標由單獨的Prometheus服務器抓取。使用聯盟，包含服務級別指標的Prometheus服務器可以從集羣Prometheus中獲取有關其特定服務的集羣資源使用指標，以便可以在該服務器內使用這兩組指標。
看這個圖:
配置信息
官方提供的配置的信息是這樣的:
scrape_configs:
- job_name: 'federate'
scrape_interval: 15s
honor_labels: true
metrics_path: '/federate'
params:
'match[]':
- '{job="prometheus"}'
- '{__name__=~"job:.*"}'
static_configs:
- targets:
- 'source-prometheus-1:9090'
- 'source-prometheus-2:9090'
- 'source-prometheus-3:9090'
在K8S裏面的監控方案
這裏先看一下，阿里的容器的監控方案:
在K8S裏面這個監控怎麼去做呢？筆者找了很多的資料，也看了阿里的 ARMS Prometheus ，阿里的設計架構如下:
阿里提供的 ARMS Prometheus 完美的監控了 Prometheus
最後結合到一個實際的情況，Prometheus使用了遠程存儲，使用的遠程存儲是 Cortex , 這個東西的作用前面有文章講過了:
