在我们的监控的过程中，单个的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 , 这个东西的作用前面有文章讲过了:
