在我们对 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 用于 Prometheus。
在主机上启动 Prometheus 后，我们编写了一个小型 Ruby 脚本，该脚本使用 Chef API 查询我们所有的主机，并写出 Prometheus 目标配置文件。我们将此文件与 file_sd_config 一起使用，以确保一旦所有主机在 Chef 中注册，就会被发现和抓取。由于 Prometheus 的开放生态系统，我们能够直接使用 Telegraf，通过简单的配置来导出主机级别的指标。
我们正在测试单个 Prometheus 可以扩展多远，并等待它崩溃。它没有！实际上，它处理了我们较新基础设施中大约 450 台主机每 15 秒抓取一次的主机级指标的负载，而资源使用量非常少。
我们每台主机上都有很多容器，因此我们预计一旦添加来自这些容器的所有内存使用指标，我们就必须开始对 Prometheus 进行分片，但 Prometheus 仍然在没有任何问题的情况下继续运行，而且仍然没有太接近饱和其资源。我们目前每 15 秒监控超过 400,000 个不同的指标，用于大约 450 台主机上的 40,000 个容器，使用单个带有 1TB 存储的 m4.xlarge prometheus 实例。您可以在下面看到此主机的主机仪表板。1TB gp2 SSD EBS 卷上的磁盘 IO 最终可能会成为限制因素。我们最初的猜测现在明显是超额配置的，但是我们在收集的指标以及要监控的主机/容器方面都在快速增长。
此时，我们为了测试而启动的 Prometheus 服务器比我们之前执行相同工作的 InfluxDB 集群可靠得多，因此我们做了一些基本工作，使其不再是单点故障。我们添加了另一个相同的节点来抓取所有相同的目标，然后添加了一个简单的故障转移方案，使用了 keepalived + DNS 更新。现在它比我们之前的系统具有更高的可用性，因此我们将面向客户的图表切换为使用 Prometheus，并拆除了旧系统。
自切换以来您看到了哪些改进？
我们之前的监控设置不可靠且难以管理。有了 Prometheus，我们有了一个可以很好地绘制大量指标的系统，并且我们的团队成员突然对使用它的新方法感到兴奋，而不是对触及我们之前使用的指标系统感到警惕。
集群也更简单了，只有两个相同的节点。随着我们的增长，我们知道我们将不得不将工作分散到更多的 Prometheus 主机上，并且已经考虑了几种方法来实现这一点。
您认为 Compose 和 Prometheus 的未来会怎样？
目前，我们仅复制了我们在以前的系统中已经收集的指标 - 客户容器的基本内存使用情况以及我们自己操作的主机级资源使用情况。下一步合乎逻辑的是使数据库团队能够从数据库容器内部将指标推送到本地 Telegraf 实例，以便我们也可以记录数据库级别的统计信息，而无需增加要抓取的目标数量。
我们还有几个其他系统想要加入 Prometheus，以获得更好的可见性。我们在 Mesos 上运行我们的应用程序，并且已经集成了基本的 Docker 容器指标，这比以前好，但是我们也希望在 Mesos 集群中有更多的基础设施组件记录到中央 Prometheus，以便我们可以拥有集中式仪表板，显示从负载均衡器到应用程序指标的所有支持系统运行状况的元素。
最终，我们将需要对 Prometheus 进行分片。由于多种原因，我们已经将客户部署分散在许多较小的集群中，因此一个合乎逻辑的选择是为每个集群迁移到较小的 Prometheus 服务器（或一对用于冗余），而不是单个全局服务器。
对于大多数报告需求，这不是一个大问题，因为我们通常不需要来自同一仪表板中不同集群的主机/容器，但是我们可能会保留一个小的全局集群，该集群具有更长的保留时间，并且仅使用记录规则从每个集群的 Prometheus 中提取少量下采样的聚合指标。