前面的系列中， prometheus和alertmanager都是单机部署的，会有单机宕机导致系统不可用情况发生。本文主要介绍下prometheus和alertmanager的高可用方案。
服务的高可靠性架构（基本ha）
promehtues是以pull方式进行设计的，因此手机时序资料都是通过prometheus本身主动发起的，而为了保证prometheus服务能够正常运行，只需要创建多个prometheus节点来收集同样的metrics即可。
架构图：
这个架构可以保证服务的高可靠性，但是并不能解决多个prometheus实例之间的资料一致性问题，也无法数据进行长期存储，且单一实例无法负荷的时候，将延伸出性能瓶颈问题，因此这种架构适合小规模进行监控。
优点：
- 服务能够提供基本的可靠性
- 适合小规模监控，只需要短期存储。
缺点：
- 无法扩展
- 数据有不一致问题
- 无法长时间保持
- 当承载量过大时，单一prometheus无法负荷。
服务高可靠性结合远端存储（基本ha + remote storage）
这种架构是在基本ha的基础上面，加入远端存储的，将数据存储在第三方的存储系统中。
该架构解决了数据持久性问题， 当prometheus server发生故障、重启的时候可以快速恢复数据，同时prometheus可以很好的进行迁移，但是这也只适合小规模的监测使用。
优点：
- 服务能够提供可靠性
- 适合小规模监测
- 数据能够持久化存储
- prometheus可以灵活迁移
- 能够得到数据还原
缺点：
- 不适合大规模监控
- 当承载量过大时，单一prometheus server无法负荷
服务高可靠性结合远端存储和联邦（基本ha + remote storage + federation）
这种架构主要是解决单一 prometheus server无法处理大量数据收集的问题，而且加强了prometheus的扩展性，通过将不同手机任务分割到不同的prometheus实力上去。
该架构通常有2种使用场景：
单一资料中心，但是有大量收集任务，这种场景行prometheus server 可能会发生性能上的瓶颈，主要是单一prometheus server 要承载大量资料书籍任务， 这个时候通过federation来将不同类型的任务分到不同的prometheus 子server 上， 再有上层完成资料聚合。
多资料中心， 在多资料中心下，这种架构也能够使用，当不同资料中心的exporter无法让最上层的prometheus 去拉取资料是， 就能通过federation来进行分层处理， 在每个资料中心建立一组收集该资料中心的prometheus server ， 在由上层的prometheus 来进行抓取， 并且也能够依据每个收集任务的承载量来部署分级，但是需要确保上下层的prometheus server 是互通的。
优点
服务能够提供可靠性
资料能够被持久性保持在第三方存储系统中
promethues server 能够迁移
能够得到资料还原
能够依据不同任务进行层级划分
适合不同规模监控
能够很好的扩展
缺点
部署架构负载
维护困难性增加
在kubernetes部署不易
------------------------------------------------------------------------------------------------------------------- 未完待续--------------------------------------------------------------------------------------------------------------