Prometheus采用Pul模型收集监控数据，服务高可用意味着同一个服务需要至少两个节点同时拉取或者切换为Push模型，使用一致性哈希，将不同实例的Metrics推送到固定推送到其中一台服务，这个模式优势是，在保障服务可用性的同时，资源消耗量少一半;新节点不需要重新配置抓取规则可以做到快速平行扩容。但缺点是，节点故障将导致历史数据丢失。应用于生产环境的监控服务，单机Promtheus往往是无法满足需求的，此时就要搭建一套Prometheus集群，此时就需要考虑:
- 服务高可用:服务要冗余备份，以消除单点故障。
- 水平可扩展:可以通过增加服务数量，线性提高服务能力。
- 数据持久化:节点故障数据不丢失、海量历史数据存储
- 数据一致性:冗余结点之间数据需要保证一致性。
选型⼀
Prometheus 根据功能或服务维度进行拆分，即如果要采集的服务比较多，一个Prometheus 实例就配置成仅采集和存储某一个或某一部分服务的指标，这样根据要采集的服务将 Prometheus 拆分成多个实例分别去采集，也能一定程度上达到水平扩容的目的。
优点：
- 服务被拆分给多个prometheus实例例收集，从而降低了单实例的性能瓶颈
- 不同的prometheus实例配置可以不同
- 拆分存储，分摊采集指标的量
缺点
- 统⼀查询入⼝不统⼀，每个prometheus都是一个查询入口
- 采集数据依然存在本地，受本地磁盘容量和io限制
选型⼆
针对选型一，一个Prometheus实例可能连这单个服务的采集任务都扛不住。
prometheus需要向这个服务所有后端实例发请求采集数据，由于后端实例数量规模太大，采集并发量就会很高，一方面对节点的带宽、CPU、磁盘lo都有一定的压力，另一方面Prometheus使用的磁盘空间有限，采集的数据量过大很容易就将磁盘塞满了，通常要做一些取舍才能将数据量控制在一定范围，但这种取舍也会降低数据完整和精确程度，不推荐这样做。那么我们可以给这种大规模类型的服务做一下分片(Sharding)，将其拆分成多个group，让一个Prometheus 实例仅采集这个服务背后的某一个group 的数据，这样就可以将这个大体量服务的监控数据拆分到多个Prometheus 实例上。
优点︰
- 解决单个服务监控指标大，利用切片方式让不同prometheus负责不同分片
- 可以做Prometheus水平扩容
缺点︰
- 加剧了监控数据落盘的分散程度，使用grafana查询数据依然需要添加多个数据源
- 不同数据源之间的数据还不能聚合查询
选型三
可以让Prometheus 不负责存储，仅采集数据并通过remote write接口方式写入远程存储的adapter，远程存储使用OpenTSDB或InfluxDB这些支持集群部署的时序数据库。然后Grafana添加我们使用的时序数据库作为数据源来查询监控数据来展示。
优点
- 数据存储远程写入，实现单数据源的查询
缺点:
- 查询语句得使用远程数据源的语法，并不能使用prometheus的promeQL语法查询
选型四
虽然上面我们通过一些列操作将Prometheus进行了分布式改造，但并没有解决Prometheus 本身的高可用问题，即如果其中一个实例挂了，数据的查询和完整性都将受到影响，那么我们可以将所有Prometheus实例都使用两个相同副本，分别挂载数据盘，它们都采集相同的服务，所以它们的数据是一致的，查询它们之中任意一个都可以，所以可以在它们前面再挂一层负载均衡，所有查询都经过这个负载均衡分流到其中一台Prometheus，如果其中一台挂掉就从负载列表里踢掉不再转发。
优点:
- 保障了prometheus的高可用
缺点:
- 数据并不能保证完全一致，当其中一台故障恢复后，他将丢失该时间的数据
选型五
thanos架构，可以帮我们简化分布式 Prometheus的部署与管理，并提供了一些的高级特性︰全局视图，长期存储，高可用，该架构使用grpc保持各个组件的通讯，sidecar组件负责连接Prometheus，将其数据提供给Thanos Query查询，并且/或者将其上传到对象存储，以供长期存储。Query组件实现了Prometheus APl，将来自下游组件提供的数据进行聚合最终返回给查询数据的client(如grafana)，类似数据库中间件。Thanos Store Gateway组件将对象存储的数据暴露给Thanos Query去查询,Thanos Compact组件将对象存储中的数据进行压缩和降低采样率,大时间区间监控数据查询的速度。Thanos Ruler组件对监控数据进行评估和告警，还可以计算出新的监控数据，将这些新数据提供给Thanos Query查询并且/或者上传到对象存储，以供长期存储。
优点:
- 采集数据可永久性保存
- 全局Query入口查询支持PromeQL语法。支持监控数据的聚合和去重
- 保障prometheus的高可用
缺点︰
- sidecar如果分布在不同地域，容易造成较高延迟，查询速度会较慢。但可以用Receiver模式(还不稳定)
