Prometheus高可用方案

1.基本HA：服务可用性

此方案用户只需要部署多套Prometheus Server实例，并且采集相同的Exporter目标。 基本的HA模式只能确保Promthues服务的可用性问题，但是不解决Prometheus Server之间的数据一致性问题以及持久化问题(数据丢失后无法恢复)，也无法进行动态的扩展。因此这种部署方式适合监控规模不大，Promthues Server也不会频繁发生迁移的情况，并且只需要保存短周期监控数据的场景。

部署架构图

Promethues通过Pull机制进行数据采集，要确保Promethues服务的可用性，只需要部署多套Prometheus Server实例，并且采集相同的Exporter目标, 通过负载均衡访问多个prometheus实例, 即可实现基本的高可用功能。

基本的HA模式只能确保Promethues服务的可用性问题，但是不解决Prometheus Server之间的数据一致性问题以及持久化问题，也无法进行动态的扩展。适合监控规模不大，Promethues Server也不会频繁发生迁移的情况，并且只需要保存短周期监控数据的场景。

2.基本HA+远端存储

在基本HA模式的基础上通过添加Remote Storage存储支持，将监控数据保存在第三方存储服务上。

在解决了Promethues服务可用性的基础上，同时确保了数据的持久化，当Promethues Server发生宕机或者数据丢失的情况下，可以快速的恢复。 同时Promethues Server能很好的进行迁移. 该方案适用于监控规模不大，希望能够将监控数据持久化，同时能够确保Promethues Server的可迁移性的场景。

远程存储解决方案

Prometheus的本地存储在可扩展性和耐用性方面受到单个节点的限制, 无法持久化数据，无法存储大量历史数据，同时也无法灵活扩展和迁移. Prometheus官方没有尝试解决Prometheus本身的集群存储问题，而是提供了一组允许与远程存储系统集成的接口, 将数据保存到任意第三方的存储服务中，实现远程存储。

Prometheus以两种方式与远程存储系统集成：

Prometheus可以以标准格式将其提取的样本写入远程URL；
Prometheus可以以标准格式从远程URL读取（返回）样本数据；
Prometheus远端存储的原理图如下所示：

Prometheus定义了同远端存储的读写接口，交互协议使用protocol buffer定义，传输基于HTTP；一个存储系统如果要支持Prometheus，仅需要实现一个adapter层，将Prometheus的的读写请求转换为其内部的格式来处理。

InfluxDB

Influxdb是目前Prometheus支持的最好的时序型数据库,也是目前相对主流的时序数据库,选用Influxdb来作为Prometheus的远程存储是目前的最佳选择, 解锁本地存储的限制, 解决Prometheus server高可用的数据一致性和持久化问题。
不足之处是Influxdb的集群功能只有商业版本才支持, 开源版本只能部署单机版, 解决办法是使用公有云上的时序数据库产品。

3.联邦集群

当单台Promethues Server无法处理大量的采集任务时，可以考虑基于Prometheus联邦集群的方式将监控采集任务划分到不同的Promethues实例当中, 即在任务级别做功能分区。

适用场景：

场景一：单数据中心 + 大量的采集任务

这种场景下Promethues的性能瓶颈主要在于大量的采集任务，因此需要利用Prometheus联邦集群的特性，将不同类型的采集任务划分到不同的Promethues子服务中，从而实现功能分区。例如一个Promethues Server负责采集基础设施相关的监控指标，另外一个Prometheus Server负责采集应用监控指标。再由上层Prometheus Server实现对数据的汇聚。

场景二：多数据中心

这种模式也适合于多数据中心的情况，当Promethues Server无法直接与数据中心中的Exporter进行通讯时，在每一个数据中部署一个单独的Promethues Server负责当前数据中心的采集任务。这样可以避免进行大量的网络配置，只需要确保主Promethues Server实例能够与当前数据中心的Prometheus Server通讯即可。 中心Promethues Server负责实现对多数据中心数据的聚合。