继续我们对 Prometheus 用户的系列采访，Compose 讲述了他们从 Graphite 和 InfluxDB 到 Prometheus 的监控历程。
您能介绍一下您自己和 Compose 吗？
Compose 为全球开发者提供生产就绪的数据库集群服务。应用程序开发者可以通过我们，只需点击几下即可在几分钟内获得一个多主机、高可用、自动备份且安全的数据库。这些数据库部署会随着需求增加而自动扩容，这样开发者就可以专注于构建他们出色的应用程序，而不是管理数据库。
我们在 AWS、Google Cloud Platform 和 SoftLayer 的每个区域都拥有数十个主机集群，每个区域至少有两个可用区。每个集群都跨越支持的可用区，并承载着大约1000个在其私有网络中的高可用数据库部署。更多的区域和提供商正在开发中。
在使用 Prometheus 之前的监控经验是怎样的？
在使用 Prometheus 之前，我们尝试了多种不同的指标系统。我们尝试的第一个系统是 Graphite，最初运行得相当不错，但我们必须存储的大量不同指标，加上 Whisper 文件在磁盘上的存储和访问方式，很快就使我们的系统不堪重负。虽然我们知道 Graphite 可以相对容易地进行水平扩展，但构建一个集群成本会很高。InfluxDB 看起来更有希望，所以我们开始尝试它的早期版本，并且在相当长一段时间内运行良好。再见了，Graphite。
早期版本的 InfluxDB 偶尔会出现数据损坏问题。我们不得不半定期地清除所有指标。这对我们来说通常不是毁灭性的损失，但很令人恼火。持续承诺但从未实现的功能坦率地说让我们感到厌倦。
您为什么决定考察 Prometheus？
与其他选项相比，它似乎结合了更高的效率和更简单的操作。
基于拉取的指标收集一开始让我们感到困惑，但我们很快就意识到了它的好处。最初看来，在我们每个主机上通常有数百个带有各自指标的容器的环境中，它的扩展性可能会太笨重，但通过将其与 Telegraf 结合使用，我们可以安排每个主机通过一个 Prometheus scrape 目标导出其所有容器的指标（以及其总体资源指标）。
您是如何过渡的？
我们使用 Chef，所以我们启动了一个带有大型 EBS 卷的较大实例，然后直接找到了一个针对 Prometheus 的社区 Chef cookbook。
在主机上启动 Prometheus 后，我们编写了一个小型 Ruby 脚本，使用 Chef API 查询所有主机，并生成一个 Prometheus target 配置文件。我们将此文件与 file_sd_config 结合使用，以确保所有主机在注册到 Chef 后立即被发现和抓取。得益于 Prometheus 开放的生态系统，我们能够使用 Telegraf，只需简单的配置即可直接导出主机级别的指标。
我们当时正在测试单个 Prometheus 的扩展能力，并等待它崩溃。它没有崩溃！事实上，在我们较新的基础设施上，它以非常低的资源消耗处理了每15秒抓取大约450个主机的主机级别指标的负载。
每个主机上有很多容器，所以我们原本预计一旦也添加了所有容器的内存使用指标后，就需要开始分片 Prometheus，但 Prometheus 只是持续运行，没有任何问题，也没有接近资源饱和。目前，我们使用单个 m4.xlarge Prometheus 实例和 1TB 存储，每15秒监控大约450个主机上40,000个容器的超过400,000个不同指标。您可以在下方看到该主机的仪表板。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 中适量下采样和聚合的指标。