Compose 访谈

继续我们关于 Prometheus 用户访谈的系列，Compose 讲述了他们从 Graphite 和 InfluxDB 到 Prometheus 的监控历程。

您能介绍一下您自己以及 Compose 的业务吗？

Compose  作为一项服务，为全球开发者提供生产级的数据库集群。开发者可以轻松地在我们这里创建多主机、高可用、自动备份且安全的数据库，几分钟内即可准备就绪。这些数据库部署还会随着需求的增长而自动扩展，这样开发者就可以专注于构建自己的优秀应用程序，而不是管理数据库。

我们在 AWS、Google Cloud Platform 和 SoftLayer 的至少两个区域拥有数十个主机集群。每个集群跨越可用区（在支持的情况下），并托管约 1000 个位于各自私有网络的高可用数据库部署。更多的区域和提供商正在开发中。

在使用 Prometheus 之前，您的监控体验是怎样的？

在 Prometheus 之前，我们尝试过多种不同的指标系统。我们尝试的第一个系统是 Graphite ，起初效果还不错，但我们需要存储的海量不同指标，加上 Whisper 文件在磁盘上的存储和访问方式，很快就压垮了我们的系统。虽然我们知道 Graphite 可以相对轻松地水平扩展，但这将是一个昂贵的集群。 InfluxDB  看起来更有希望，于是我们开始尝试它早期的一些版本，它在很长一段时间内似乎运行良好。告别 Graphite。

InfluxDB 的早期版本偶尔会出现数据损坏问题。我们不得不定期清除所有指标。这对我们来说通常不是毁灭性的损失，但令人烦恼。那些从未实现的持续承诺，坦白说让我们感到厌倦。

你们为什么决定研究 Prometheus？

它似乎比其他选项结合了更好的效率和更简单的操作。

拉取式的指标收集起初让我们感到困惑，但我们很快就意识到了它的好处。起初，我们认为这在我们的环境中可能过于重量级，难以很好地扩展，因为我们经常在每个主机上有数百个容器及其自己的指标，但通过将其与 Telegraf 结合，我们可以安排让每个主机通过一个 Prometheus scrape 目标导出其所有容器的指标（以及其整体资源指标）。

你们是如何过渡的？

我们是 Chef 用户，所以我们搭建了一个拥有大型 EBS 卷的庞大实例，然后直接使用了一个 社区 Chef cookbook  来安装 Prometheus。

在 Prometheus 宿主服务器上运行后，我们编写了一个简单的 Ruby 脚本，该脚本使用 Chef API 查询所有主机，并写出一个 Prometheus 目标配置文件。我们使用这个文件配合 `file_sd_config` 来确保所有主机在注册到 Chef 后都能立即被发现并抓取。得益于 Prometheus 开放的生态系统，我们能够直接使用 Telegraf，只需简单的配置即可导出主机级别的指标。

我们正在测试单个 Prometheus 的扩展能力，并等待它崩溃。它并没有！事实上，它以极低的资源使用量处理了每 15 秒抓取约 450 个主机（在我们较新的基础设施上）的主机级别指标的负载。

我们在每个主机上都有很多容器，所以我们原本以为在添加了所有内存使用量指标后，需要开始分片 Prometheus，但 Prometheus 毫无问题地继续运行，而且资源使用率仍然不高。目前，我们通过单个 m4.xlarge 2TB 存储的 Prometheus 实例，每 15 秒监控超过 400,000 个不同的指标，涉及约 40,000 个容器和 450 个主机。您可以在下方看到此主机的宿主仪表板。1TB gp2 SSD EBS 卷上的磁盘 IO 最终可能会成为瓶颈。我们最初的估计目前来说是过度配置了，但我们在收集的指标以及需要监控的主机/容器数量方面都在快速增长。

此时，我们为了测试而搭建的 Prometheus 服务器比之前负责相同工作的 InfluxDB 集群可靠得多，因此我们进行了一些基本工作，使其不再是单点故障。我们添加了另一个相同的节点，抓取所有相同的目标，然后添加了一个简单的故障转移方案，使用 keepalived + DNS 更新。现在它的高可用性比我们之前的系统要好，所以我们切换到使用 Prometheus 来显示面向客户的图表，并拆除了旧系统。

切换后你们看到了哪些改进？

我们之前的监控设置不可靠且难以管理。有了 Prometheus，我们拥有一个能够很好地绘制大量指标图表的系统，而且我们的团队成员对使用它的新方法感到兴奋，而不是像以前那样对接触指标系统感到担忧。

集群也更简单，只有两个相同的节点。随着我们的发展，我们知道我们将不得不将工作分片到更多的 Prometheus 主机上，并且已经考虑了几种方法来实现这一点。

您认为 Compose 和 Prometheus 的未来会怎样？

目前，我们只复制了以前系统中已经收集的指标——客户容器的基本内存使用情况以及我们自己运营的主机级别资源使用情况。接下来的合乎逻辑的步骤是让数据库团队能够从 DB 容器内部将指标推送到本地 Telegraf 实例，这样我们就可以记录数据库级别的统计数据，而无需增加需要抓取的目標数量。

我们还有其他几个系统想要接入 Prometheus 以获得更好的可见性。我们在 Mesos 上运行应用程序，并且已经集成了基本的 Docker 容器指标，这比以前要好，但我们也希望 Mesos 集群中的更多基础设施组件能够记录到中央 Prometheus，这样我们就可以拥有中心化的仪表板，显示从负载均衡器到应用程序指标的所有支持系统的健康状况。

最终，我们将需要分片 Prometheus。我们已经出于各种原因将客户部署分拆到许多较小的集群中，因此一个合乎逻辑的选择是将每个集群迁移到一个较小的 Prometheus 服务器（或一对用于冗余）上，而不是一个单一的全局服务器。

对于大多数报告需求来说，这不是大问题，因为我们通常不需要来自不同集群的主机/容器在同一个仪表板上，但我们可能会保留一个较小的全局集群，拥有更长的保留期，并且只使用 Recording Rules 从每个集群的 Prometheus 中收集少量下采样和聚合的指标。