内容：记录prometheus的部署方案
Prometheus框架图：
Prometheus高可用部署方案：
方案1：HA部署
Promethues通过Pull机制进行数据采集，要确保Promethues服务的可用性，只需要
部署多套Prometheus Server实例，并且采集相同的Exporter目标, 通过负载均衡
访问多个prometheus实例, 即可实现基本的高可用功能。
基本的HA模式只能确保Promethues服务的可用性问题，但是不解决Prometheus Server
之间的数据一致性问题以及持久化问题，也无法进行动态的扩展。适合监控规模不大，
Promethues Server也不会频繁发生迁移的情况，并且只需要保存短周期监控数据的场景。
优点：提高prometheus的高可用，避免单点宕机
缺点：1、prometheus的数据有冗杂，下游的告警服务会收到来自多个prometheus的相同告警，
需要做去重处理（比如：altermanager集群利用gossip协议宣告规则，实现去重）
2、下游服务会收到上游多个prometheus的重复采集，增加了他的压力
方案2: 基本HA+远程存储
在基本HA模式的基础上通过添加Remote Storage存储支持，将监控数据保存在第三方存储服务上。
在解决了Promethues服务可用性的基础上，同时确保了数据的持久化，当Promethues Server
发生宕机或者数据丢失的情况下，可以快速的恢复。 同时Promethues Server能很好的进行迁移.
该方案适用于监控规模不大，希望能够将监控数据持久化，同时能够确保Promethues Server的
可迁移性的场景。
远程存储解决方案：
Prometheus的本地存储在可扩展性和耐用性方面受到单个节点的限制, 无法持久化数据，无法存储
大量历史数据，同时也无法灵活扩展和迁移. Prometheus官方没有尝试解决Prometheus本身的
集群存储问题，而是提供了一组允许与远程存储系统集成的接口, 将数据保存到任意第三方的存储
服务中，实现远程存储。
Prometheus以两种方式与远程存储系统集成：
1、Prometheus可以以标准格式将其提取的样本写入远程URL。
2、Prometheus可以以标准格式从远程URL读取（返回）样本数据。
方案3：Promethues邦联集群
在每个数据中心部署单独的Prometheus Server，用于采集当前数据中心监控数据。并由一个中心
的Prometheus Server负责聚合多个数据中心的监控数据。这一特性在Promthues中称联邦集群。
功能分区，即通过联邦集群的特性在任务级别对Prometheus采集任务进行划分，以支持规模的扩展。
例如如下所示，可以在各个数据中心中部署多个Prometheus Server实例。每一个Prometheus
实例只负责采集当前数据中心中的一部分任务(Job)，再通过中心Prometheus实例进行聚合。
方案4：Promethues邦联集群+HA
当单台Promethues Server无法处理大量的采集任务时，可以考虑基于Prometheus联邦集群的
方式将监控采集任务划分到不同的Promethues实例当中, 即在任务级别做功能分区。
场景一：单数据中心 + 大量的采集任务
这种场景下Promethues的性能瓶颈主要在于大量的采集任务，因此需要利用Prometheus联邦集群
的特性，将不同类型的采集任务划分到不同的Promethues子服务中，从而实现功能分区。
例如：一个Promethues负责采集基础设施相关的监控指标，另外一个Prometheus负责采集应用监
控指标。再由上层Prometheus Server实现对数据的汇聚。
场景二：多数据中心
这种模式也适合于多数据中心的情况，当Promethues Server无法直接与数据中心中的Exporter
进行通讯时，在每一个数据中部署一个单独的Promethues Server负责当前数据中心的采集任务。
这样可以避免进行大量的网络配置，只需要确保主Promethues Server实例能够与当前数据中心的
Prometheus Server通讯即可。 中心Promethues Server负责实现对多数据中心数据的聚合。
远程存储如何处理重复数据点：
measurement的名字、tag set和时间戳唯一标识一个数据点。如果提交的数据点跟已有的数据点
相比，具有相同measurement、tag set和时间戳，但具有不同field set，那么该数据点的
field set会变为旧field set和新field set的并集，如果有任何冲突以新field set为准。
这是预期的结果。Prometheus注意点：
1、建议使用远程存储：
本地存储带来了数据持久化的问题，特别是在像Kubernetes这样的动态集群环境下，若Promthues
的实例被重新调度，那所有历史监控数据都会丢失。 其次本地存储也意味着Prometheus不适合保存
大量历史数据(一般Prometheus推荐只保留几周或者几个月的数据)。最后本地存储也导致
Prometheus无法进行弹性扩展。为了适应这方面的需求，Prometheus提供了remote_write
和remote_read的特性，支持将数据存储到远端和从远端读取数据。通过将监控样本采集和数据
存储分离，解决Prometheus的持久化问题。
2、下游待监控的服务太多时，建议使用Prometheus联邦集群：
由于Prometheus基于Pull模型，当有大量的Target需要采样本时，单一Prometheus实例在数据
抓取时可能会出现一些性能问题，联邦集群的特性可以让Prometheus将样本采集任务划分到不同的
Prometheus实例中，并且通过一个统一的中心节点进行聚合，从而可以使Prometheuse可以根据
规模进行扩展。
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
