与 Compose 的访谈

在我们的Prometheus用户访谈系列中，Compose讲述了他们从Graphite和InfluxDB转向Prometheus的监控历程。

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

Compose 为全球开发者提供生产就绪的数据库集群即服务。应用程序开发人员只需点击几下，即可在数分钟内获得一个多主机、高可用、自动备份且安全的数据库。这些数据库部署会随着需求增加而自动扩展，因此开发人员可以专注于构建出色的应用程序，而不必将时间花费在管理数据库上。

我们在AWS、Google Cloud Platform和SoftLayer的每个区域都拥有数十个主机集群，每个区域至少有两个。每个集群都跨越其支持的可用区，承载着约1000个部署在其私有网络中的高可用数据库。更多区域和提供商正在开发中。

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

在Prometheus之前，我们尝试了许多不同的度量系统。我们尝试的第一个系统是Graphite，它最初运行得相当好，但我们需要存储的各种度量数据量巨大，再加上Whisper文件在磁盘上的存储和访问方式，很快就使我们的系统过载。虽然我们知道Graphite可以相对容易地进行水平扩展，但这将是一个昂贵的集群。InfluxDB看起来更有前景，所以我们开始尝试其早期版本，它在很长一段时间内似乎运行良好。再见了，Graphite。

InfluxDB的早期版本偶尔会出现数据损坏问题。我们不得不半定期地清除所有度量数据。对我们来说，这通常不是毁灭性的损失，但却令人恼火。更令人沮丧的是，那些承诺的功能从未兑现。

您为什么决定关注Prometheus？

与其他选项相比，它似乎在提高效率的同时简化了操作。

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

您是如何进行过渡的？

我们是一家使用Chef的公司，因此我们启动了一个带有大EBS卷的较大实例，然后直接使用了适用于Prometheus的社区Chef Cookbook。

在主机上启动Prometheus后，我们编写了一个小型Ruby脚本，该脚本使用Chef API查询所有主机，并输出一个Prometheus目标配置文件。我们将此文件与file_sd_config一起使用，以确保所有主机在向Chef注册后立即被发现并抓取。得益于Prometheus开放的生态系统，我们能够直接使用Telegraf，通过简单的配置导出主机级别的度量数据。

我们当时正在测试单个Prometheus能扩展到什么程度，并等待它崩溃。但它没有！事实上，它以极低的资源使用率，处理了我们新基础设施中大约450个主机每15秒抓取一次主机级别度量数据的负载。

每个主机上都有大量容器，所以我们曾预计一旦也加入了这些容器的所有内存使用度量数据，就需要开始对Prometheus进行分片，但Prometheus却毫无波澜地继续运行，并且没有接近其资源饱和。目前，我们使用一个配备1TB存储的m4.xlarge Prometheus实例，每15秒监控450个主机上大约40,000个容器的超过400,000个独立度量数据。您可以在下方看到我们此主机的主机仪表板。1TB gp2 SSD EBS卷的磁盘IO最终可能会成为限制因素。我们最初的估计目前是过度配置的，但我们在度量数据收集以及要监控的主机/容器数量方面都在快速增长。

此时，我们用于测试的Prometheus服务器比之前做同样工作的InfluxDB集群可靠得多，因此我们做了一些基础工作，使其不再是单点故障。我们添加了另一个相同的节点，抓取所有相同的目标，然后通过keepalived + DNS更新添加了一个简单的故障转移方案。现在，这比我们之前的系统具有更高的可用性，于是我们将面向客户的图表切换到使用Prometheus，并拆除了旧系统。

切换后您看到了哪些改进？

我们之前的监控设置不可靠且难以管理。有了Prometheus，我们拥有了一个能很好地绘制大量度量数据图表的系统，我们的团队成员突然对使用Prometheus的新方式感到兴奋，而不是像以前那样对接触度量系统感到警惕。

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

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

目前，我们只复制了在以前系统中已经收集到的度量数据——客户容器的基本内存使用情况以及我们自身操作的主机级资源使用情况。下一步是让数据库团队能够从数据库容器内部将度量数据推送到本地Telegraf实例，这样我们也可以记录数据库级别的统计数据，而无需增加抓取目标的数量。

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

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

对于大多数报告需求来说，这不是一个大问题，因为我们通常不需要在同一个仪表板中查看来自不同集群的主机/容器。但我们可能会保留一个小型全局集群，具有更长的保留期，并仅使用记录规则（Recording Rules）从每个集群的Prometheus中获取少量降采样和聚合的度量数据。