Compose 访谈
2016年9月21日作者 Brian Brazil
在 Prometheus 用户系列访谈中，Compose 分享了他们从 Graphite 和 InfluxDB 迁移到 Prometheus 的监控之旅。
能介绍一下您自己以及 Compose 的业务吗？
Compose 为全球开发者提供生产就绪的数据库集群服务。应用开发者只需点击几下，即可在几分钟内获得一个具备多主机、高可用、自动备份且安全的数据库。这些数据库部署会随着需求增长自动扩容，让开发者能将精力集中在构建出色的应用上，而不是运维数据库本身。
我们在 AWS、Google Cloud Platform 和 SoftLayer 的每个平台上至少拥有两个区域，共有数十个主机集群。每个集群跨越多个可用区（如果支持），并在其私有网络中托管约 1000 个高可用的数据库实例。目前还有更多的区域和供应商正在筹备中。
在使用 Prometheus 之前，您的监控体验是怎样的？
在选择 Prometheus 之前，我们尝试过多种不同的指标系统。我们尝试的第一个系统是 Graphite ，它起初运行良好，但由于我们需要存储的指标数量庞大，加上 Whisper 文件在磁盘上的存储和访问方式，系统很快就不堪重负。虽然我们知道 Graphite 可以相对容易地实现横向扩展，但那将是一个昂贵的集群。InfluxDB 看上去前景更好，于是我们开始尝试其早期版本，它在很长一段时间里表现不错。再见，Graphite。
早期版本的 InfluxDB 有时会出现数据损坏问题。我们需要定期清理所有指标。虽然这对我们来说通常不是灾难性的损失，但确实很烦人。而关于那些迟迟未实现的功能的不断承诺，最终让我们感到疲惫。
你们为什么决定研究 Prometheus？
它似乎将更高的效率与比其他方案更简单的操作结合在了一起。
基于 Pull（拉取）的指标采集方式起初让我们感到困惑，但很快我们就意识到了它的好处。最初，我们担心在我们的环境下（每台主机上有数百个容器，每个容器都有自己的指标）这种方式可能过于笨重，无法很好地扩展。但通过将其与 Telegraf 结合使用，我们可以安排每台主机通过单个 Prometheus 抓取目标导出其所有容器的指标（以及整体资源指标）。
你们是如何过渡的？
我们是 Chef 的忠实用户，所以我们启动了一个较大的实例，配置了巨大的 EBS 卷，并直接使用了 社区提供的 Chef cookbook 来部署 Prometheus。
在主机上运行 Prometheus 后，我们编写了一个小的 Ruby 脚本，利用 Chef API 查询所有主机，并生成一个 Prometheus 目标配置文件。我们将此文件与 file_sd_config 一起使用，以确保所有主机在向 Chef 注册后能立即被发现并抓取。得益于 Prometheus 的开放生态系统，我们能够开箱即用地使用 Telegraf，只需简单的配置即可直接导出主机级指标。
我们当时正在测试单个 Prometheus 实例的极限，等着看它何时会崩溃。结果它没崩溃！事实上，在我们的新基础设施中，它处理了约 450 台主机每 15 秒抓取一次主机级指标的负载，且资源消耗极少。
由于每台主机上有大量的容器，我们预计一旦加入容器的内存使用指标，就需要开始对 Prometheus 进行分片。但 Prometheus 运行得非常平稳，完全没有达到资源瓶颈。目前，我们使用单个 m4.xlarge 的 Prometheus 实例（配备 1TB 存储），每 15 秒监控 450 台主机上约 40,000 个容器的 40 多万个不同指标。您可以在下方查看该主机的主机仪表板。1TB gp2 SSD EBS 卷上的磁盘 IO 最终可能会成为瓶颈。我们最初的预估目前看来是过度配置了，但我们在采集的指标数量和监控的主机/容器数量上都在快速增长。
到这个时候，我们用来测试的 Prometheus 服务器比之前做同样工作的 InfluxDB 集群可靠得多，因此我们做了一些基础工作来消除单点故障。我们增加了另一个完全相同的节点来抓取所有相同的目标，然后使用 keepalived + DNS 更新实现了一个简单的故障转移方案。这比我们之前的系统具备了更高可用性，于是我们将面向客户的图表切换到了 Prometheus，并拆除了旧系统。
切换后你们看到了哪些改进？
我们以前的监控设置既不可靠又难以管理。现在有了 Prometheus，我们不仅拥有了一个能很好地绘制大量指标的系统，而且团队成员也对它的新用法感到兴奋，而不是像以前那样害怕触碰监控系统。
现在的集群也更简单了，只有两个相同的节点。随着业务增长，我们知道需要将工作分片到更多的 Prometheus 实例上，并且已经考虑了实现这一目标的几种方法。
您认为 Compose 和 Prometheus 的未来会怎样？
目前，我们仅复制了之前系统中已有的指标——客户容器的基本内存使用情况以及我们自身运维的主机级资源使用情况。下一步的逻辑动作是让数据库团队能够从数据库容器内部向本地的 Telegraf 实例推送指标，这样我们无需增加抓取目标数量即可记录数据库级的统计信息。
我们还有其他几个系统希望接入 Prometheus 以获得更好的可视化效果。我们已经在 Mesos 上运行应用并整合了基本的 Docker 容器指标，这比以前有了进步，但我们还希望将 Mesos 集群中的更多基础设施组件记录到中心 Prometheus 中。这样我们可以拥有统一的仪表板，显示从负载均衡器到应用指标的所有支持系统的健康状态。
最终我们需要对 Prometheus 进行分片。出于各种原因，我们已经将客户部署分散在许多较小的集群中，因此最合理的选择是转向每个集群使用一个较小的 Prometheus 服务器（或冗余的一对），而不是使用一个全局统一的实例。
对于大多数报告需求而言，这不是大问题，因为我们通常不需要在同一个仪表板中同时查看来自不同集群的主机/容器。但我们可能会保留一个小型的全局集群，用于更长的数据保留，并仅通过 Recording Rules 从每个集群的 Prometheus 获取少量经过下采样和聚合的指标。