继续我们对 Prometheus 用户进行采访的系列，Compose 讲述了他们从 Graphite 和 InfluxDB 到 Prometheus 的监控之旅。
你能否介绍一下你自己以及 Compose 是做什么的？
Compose 为全球开发者提供生产就绪的数据库集群即服务。应用程序开发者可以来到我们这里，只需点击几下，即可在几分钟内获得一个多主机、高可用、自动备份且安全的数据库。这些数据库部署随后会随着需求的增长而自动扩展，因此开发者可以将时间花在构建出色的应用程序上，而不是运行他们的数据库。
我们在 AWS、Google Cloud Platform 和 SoftLayer 的每个平台中至少有两个区域拥有数十个主机集群。每个集群都跨越可用区（如果支持），并且托管大约 1000 个高可用数据库部署，这些部署位于它们自己的私有网络中。更多的区域和提供商正在筹备中。
在 Prometheus 之前，你们的监控经验是什么？
在 Prometheus 之前，我们尝试了许多不同的指标系统。我们尝试的第一个系统是 Graphite，它最初运行良好，但我们需要存储的不同指标的庞大数量，加上 Whisper 文件在磁盘上的存储和访问方式，很快就使我们的系统过载。虽然我们意识到 Graphite 可以相对容易地水平扩展，但这将是一个昂贵的集群。InfluxDB 看起来更有希望，所以我们开始尝试早期版本，它在很长一段时间内似乎运行良好。再见 Graphite。
早期版本的 InfluxDB 有时会出现数据损坏问题。我们经常需要清除所有指标。这对我们来说通常不是毁灭性的损失，但这令人恼火。那些持续承诺但从未兑现的功能坦率地说让我们感到厌倦。
你们为什么决定关注 Prometheus？
它似乎比其他选项更好地结合了效率和更简单的操作。
基于拉取的指标收集起初让我们感到困惑，但我们很快意识到了它的好处。最初，它似乎过于笨重，无法在我们经常在每台主机上拥有数百个带有自己指标的容器的环境中良好扩展，但通过将其与 Telegraf 结合使用，我们可以安排每台主机通过单个 Prometheus 抓取目标导出其所有容器（以及其整体资源指标）的指标。
你们是如何过渡的？
我们是一家 Chef 商店，因此我们启动了一个大型实例，带有一个大的 EBS 卷，然后直接使用了 社区 chef cookbook for Prometheus。
在主机上启动 Prometheus 后，我们编写了一个小的 Ruby 脚本，该脚本使用 Chef API 查询我们所有的主机，并写出一个 Prometheus 目标配置文件。我们将此文件与 file_sd_config 一起使用，以确保在所有主机向 Chef 注册后立即被发现和抓取。感谢 Prometheus 的开放生态系统，我们能够开箱即用地使用 Telegraf，只需一个简单的配置即可直接导出主机级指标。
我们正在测试单个 Prometheus 可以扩展到多远，并等待它崩溃。但它没有！事实上，它处理了大约 450 台主机（跨越我们较新的基础设施）每 15 秒抓取一次的主机级指标的负载，资源使用率非常低。
我们在每台主机上都有很多容器，因此我们预计一旦添加所有这些容器的内存使用情况指标，我们就必须开始分片 Prometheus，但 Prometheus 仍然继续运行，没有任何问题，并且仍然没有太接近饱和其资源。我们目前每 15 秒监控超过 400,000 个不同的指标，这些指标来自 450 台主机上的大约 40,000 个容器，使用单个 m4.xlarge prometheus 实例，带有 1TB 的存储空间。您可以在下面看到此主机的主机仪表板。1TB gp2 SSD EBS 卷上的磁盘 IO 最终可能会成为限制因素。我们最初的猜测现在远远超出了需求，但我们在收集的指标和要监控的主机/容器方面都在快速增长。
此时，我们为了测试而启动的 Prometheus 服务器比我们之前用于完成相同工作的 InfluxDB 集群要可靠得多，因此我们做了一些基本工作，使其不再是单点故障。我们添加了另一个相同的节点，抓取所有相同的目标，然后添加了一个使用 keepalived + DNS 更新的简单故障转移方案。这比我们之前的系统更具高可用性，因此我们将面向客户的图表切换为使用 Prometheus，并拆除了旧系统。
自从切换以来，你们看到了哪些改进？
我们之前的监控设置不可靠且难以管理。有了 Prometheus，我们拥有一个运行良好的系统，可以绘制大量指标，并且我们的团队成员突然对使用它的新方法感到兴奋，而不是像以前那样对接触我们使用的指标系统感到谨慎。
集群也更简单，只有两个相同的节点。随着我们的增长，我们知道我们将不得不将工作分片到更多的 Prometheus 主机上，并考虑了几种方法来做到这一点。
你们认为 Compose 和 Prometheus 的未来会怎样？
目前，我们只复制了我们在以前的系统中已经收集的指标 - 客户容器的基本内存使用情况以及我们自己操作的主机级资源使用情况。下一步合乎逻辑的步骤是使数据库团队能够从 DB 容器内部将指标推送到本地 Telegraf 实例，这样我们也可以记录数据库级统计信息，而无需增加要抓取的目标数量。
我们还有几个其他系统也希望加入 Prometheus，以获得更好的可见性。我们在 Mesos 上运行我们的应用程序，并且已经集成了基本的 Docker 容器指标，这比以前更好，但我们也希望在 Mesos 集群中拥有更多的基础设施组件记录到中央 Prometheus，这样我们就可以拥有集中的仪表板，显示从负载均衡器到应用程序指标的所有支持系统健康状况的元素。
最终我们将需要分片 Prometheus。出于各种原因，我们已经将客户部署分散到许多较小的集群中，因此一个合乎逻辑的选择是移动到每个集群一个较小的 Prometheus 服务器（或一对用于冗余），而不是单个全局服务器。
对于大多数报告需求，这不是一个大问题，因为我们通常不需要在同一个仪表板中使用来自不同集群的主机/容器，但我们可能会保留一个小型的全局集群，它具有更长的保留期，并且仅使用来自每个集群 Prometheus 的少量下采样和聚合指标，使用 Recording Rules。