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-based）的指标收集方式起初让我们感到困惑，但我们很快就意识到了它的好处。最初，我们觉得这种方式可能过于笨重，无法在我们的环境中很好地扩展，因为我们通常在每台主机上有数百个带有各自指标的容器。但通过将它与 Telegraf 结合，我们可以安排每台主机通过单个 Prometheus 抓取目标，导出其所有容器的指标（以及其整体资源指标）。
你们是如何过渡的？
我们是一家使用 Chef 的公司，所以我们启动了一个带有大 EBS 卷的较大型实例，然后直接使用了一个用于 Prometheus 的社区 chef cookbook 。
在主机上部署了 Prometheus 后，我们编写了一个小型的 Ruby 脚本，该脚本使用 Chef API 查询我们所有的主机，并生成一个 Prometheus 目标配置文件。我们将此文件与 file_sd_config 一起使用，以确保所有主机在向 Chef 注册后立即被发现和抓取。得益于 Prometheus 的开放生态系统，我们能够直接使用 Telegraf，只需一个简单的配置即可导出主机级别的指标。
我们当时正在测试单个 Prometheus 能扩展到什么程度，并等着它崩溃。但它没有！事实上，它处理了我们较新基础设施中大约 450 台主机每 15 秒抓取一次的主机级指标负载，资源使用率非常低。
我们每台主机上有很多容器，所以我们预计一旦我们把这些容器的所有内存使用指标也加进去，就必须开始对 Prometheus 进行分片。但 Prometheus 只是继续运行，没有任何问题，并且仍然没有接近其资源饱和。目前，我们使用一个 m4.xlarge 实例和 1TB 存储的 Prometheus，监控着 450 台主机上约 40,000 个容器的超过 400,000 个不同指标，每 15 秒抓取一次。您可以在下面看到这台主机的仪表盘。这个 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 中降采样和聚合的少量指标。