Prometheus 高可用方案

本文介绍了 Prometheus 的高可用官方方案和自研高可用方案。

一、现实可用的小规模高可用方案

关于 Prometheus 的高可用，官方文档中只提供了一个解决方案，具体实现方式如下：

使用两个 Prometheus 主机监控同样的目标，然后有告警出现，也会发送同样的告警给 Alertmanager，然后使用 Alertmanager 自身的去重告警功能，只发出一条告警出来。从而实现了 prometheus 高可用的一个架构。 基于此架构，我们还可以使用 keepalived 做双机热备，通过 VIP 与 grafana 相连。实现一个完整的带 web 界面展示告警的高可用 Prometheus 监控架构。

根据查找的资料，可知 Prometheus 的监控数量和 Prometheus 主机的内存和磁盘大小的关系表。

根据表格中数据，我们可以用两台 8G 内存，磁盘大小为 100G 的 Prometheus 主机做主备架构，进行 500 个节点以下的基础架构的监控，然后由于抓取间隔和数据留存时间的设定是直接关乎内存和磁盘空间的使用率，所以我们可以通过调整这两点，来调整内存和磁盘空间到合适的值。

二、大规模监控的高可用方案

根据官方文档，Prometheus 有一个面向于大规模目标监控的功能** FEDERATION **联邦机制，是指从其它 Prometheus 主机上抓取特定的数据到一个汇总的 Prometheus 主机中，既然是从其它 Prometheus 主机汇总而来，那么数据量会很大，难以长久储存在主机本地，所以我们需要使用 Prometheus 的远程读写数据库的功能，来远程保存至第三方数据库。 而这个用于汇总的 Prometheus 主机，我们也使用主备两台主机做高可用处理，不过与第三方数据库之间需要用一个 adapter 工具，来做主备数据库传输切换。如下图所示。

在这里第三方存储是使用的 PostgreSQL + TimescaleDB，而 adapter 是用的官方开发的 Prometheus-postgresql-adpter 自带 leader 切换的功能，当设置好 Prometheus 和 adapter 后，如果 adapter 长时间没有收到对应的 Prometheus 的数据，那么它会自动锁定然后切换到备用 adapter，备用 adpter 会将自己所对应的 Prometheus 主机的数据发往第三方存储。 也就是说，这两台 Prometheus 主机都是会实时接收其它相同 Prometheus 主机的数据，然后只有其中一方的数据会被标识为 leader 的 adapter 发送到第三方存储中。完整架构图如下。

三、总结

不管是第一章的小规模监控高可用方案还是第二章的大规模监控高可以方案，主要应用的还是 Prometheus 官方文档提到高可用方法和 Prometheus 的联邦机制机远程读写存储的功能。而主备切换的工具 keepalive 和 Prometheus-postgresql-adpter，以及远程数据库 PostgreSQL+TimescaleDB，这些都可以替换成 Nginx proxy、服务注册工具 consul，远程存储 Thanos，我们可以根据实际需求做测试，再决定使用哪些第三方工具。