KOCA版本 ：all
KOCA模块 ：
模块版本 :
场景 ：微服务架构高可用部署
问题 ：
报错细节 ：
AMO高可用部署方案：
⽅案选择
1、日志系统高可用
2、监控系统⾼可⽤（官⽹推荐⽅案）
2.1 基本HA：服务可⽤性
由于Promthues的Pull机制的设计，为了确保Promthues服务的可⽤性，⽤户只需要部署多套
Prometheus Server实例，并且采集相同的Exporter⽬标即可。
基本的HA模式只能确保Promthues服务的可⽤性问题，但是不解决Prometheus Server之间的数据⼀致
性问题以及持久化问题(数据丢失后⽆法恢复)，也⽆法进⾏动态的扩展。因此这种部署⽅式适合监控规
模不⼤，Promthues Server也不会频繁发⽣迁移的情况，并且只需要保存短周期监控数据的场景。
⽤此种⽅案，如果要持久化存储，可以存到ES中，Integrations | Prometheus
#remote-endpoints-and-storage
2.2 基本HA + 远程存储
在基本HA模式的基础上通过添加Remote Storage存储⽀持，将监控数据保存在第三⽅存储服务上。
在解决了Promthues服务可⽤性的基础上，同时确保了数据的持久化，当Promthues Server发⽣宕机或
者数据丢失的情况下，可以快速的恢复。 同时Promthues Server可能很好的进⾏迁移。因此，该⽅案适⽤于⽤户监控规模不⼤，但是希望能够将监控数据持久化，同时能够确保Promthues Server的可迁移性的场景。
2.3 基本HA + 远程存储 + 联邦集群
当单台Promthues Server⽆法处理⼤量的采集任务时，⽤户可以考虑基于Prometheus联邦集群的⽅式将监控采集任务划分到不同的Promthues实例当中即在任务级别功能分区。
这种部署⽅式⼀般适⽤于两种场景：
场景⼀：单数据中⼼ + ⼤量的采集任务
这种场景下Promthues的性能瓶颈主要在于⼤量的采集任务，因此⽤户需要利⽤Prometheus联邦集群的特性，将不同类型的采集任务划分到不同的Promthues⼦服务中，从⽽实现功能分区。例如⼀个
Promthues Server负责采集基础设施相关的监控指标，另外⼀个Prometheus Server负责采集应⽤监控
指标。再有上层Prometheus Server实现对数据的汇聚。
场景⼆：多数据中⼼
这种模式也适合与多数据中⼼的情况，当Promthues Server⽆法直接与数据中⼼中的Exporter进⾏通讯
时，在每⼀个数据中部署⼀个单独的Promthues Server负责当前数据中⼼的采集任务是⼀个不错的⽅
式。这样可以避免⽤户进⾏⼤量的⽹络配置，只需要确保主Promthues Server实例能够与当前数据中⼼
的Prometheus Server通讯即可。 中⼼Promthues Server负责实现对多数据中⼼数据的聚合
3、告警
Alertmanager引⼊了Gossip机制。Gossip机制为多个Alertmanager之间提供了信息传递的机制。确保及时在多个Alertmanager分别接收到相同告警信息的情况下，也只有⼀个告警通知被发送给Receiver。
