DigitalOcean 采访

在我们对 Prometheus 用户进行的一系列采访中，DigitalOcean 谈论了他们如何使用 Prometheus。Carlos Amedee 还在 PromCon 2016 上谈到了 推广的社会层面 。

您能介绍一下自己以及 DigitalOcean 的业务吗？

我叫 Ian Hansen，在平台指标团队工作。DigitalOcean  提供简单的云计算服务。迄今为止，我们已在 13 个区域创建了 2000 万个 Droplets（SSD 云服务器）。我们最近还发布了一款新的块存储产品。

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

在 Prometheus 之前，我们运行 Graphite  和 OpenTSDB 。Graphite 用于小型应用程序，OpenTSDB 用于通过 Collectd  收集所有物理服务器的指标。Nagios  会从这些数据库中拉取数据以触发警报。我们仍然使用 Graphite，但不再运行 OpenTSDB。

你们为什么决定研究 Prometheus？

我对 OpenTSDB 感到沮丧，因为我负责维护集群在线，但发现很难防范指标风暴。有时，一个团队会推出一个新的（非常“多话”的）服务，这会影响集群的总容量并损害我的 SLA。

我们能够对进入 OpenTSDB 的新指标进行黑名单/白名单管理，但除了组织流程（这很难改变/强制执行）之外，没有很好的方法来防范“多话”服务。其他团队对当时的查询语言和可视化工具感到沮丧。我与 Julius Volz 讨论了推送与拉取指标系统，当我看到我可以控制拉取什么以及拉取频率时，我真的被说服了，想尝试 Prometheus，因为这样我就可以真正控制我的 SLA。此外，我真的非常喜欢它的查询语言。

你们是如何过渡的？

我们之前通过 Collectd 收集指标并发送到 OpenTSDB。在已运行的 Collectd 设置的同时安装 Node Exporter  让我们得以开始尝试 Prometheus。我们还创建了一个自定义的 exporter 来暴露 Droplet 指标。很快，我们与 OpenTSDB 服务实现了功能对等，并开始关闭 Collectd，然后关闭 OpenTSDB 集群。

人们非常喜欢 Prometheus 及其附带的可视化工具。突然间，我的小型指标团队积压了大量工作，我们无法足够快地满足大家的需求。因此，我们没有为人们的服务提供和维护 Prometheus，而是着手创建工具，以便其他团队能够尽可能轻松地运行自己的 Prometheus 服务器，并运行我们在公司中使用的常用 exporter。

一些团队已经开始使用 Alertmanager，但我们仍然保留从现有监控工具中拉取 Prometheus 的概念。

切换后你们看到了哪些改进？

我们改进了对虚拟机监控程序（hypervisor）机器的洞察力。我们从 Collectd 和 Node Exporter 中获取的数据大致相同，但对于我们的 Go 语言（golang）开发团队来说，创建新的自定义 exporter 来暴露每个虚拟机监控程序上运行的服务特有的数据要容易得多。

我们正在暴露更好的应用程序指标。学习和教授如何创建可以在以后正确聚合的 Prometheus 指标变得更容易。使用 Graphite 时，很容易创建一种指标，由于点分隔的名称结构不正确，导致以后无法以某种方式聚合。

创建警报比我们以前更快、更简单，而且使用的是熟悉的语言。这使得团队能够为他们了解和理解的服务创建更好的警报，因为他们可以快速迭代。

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

我们正在继续研究如何让 DigitalOcean 的团队尽可能轻松地收集指标。目前，各个团队都在运行自己的 Prometheus 服务器来监控他们关心的事物，这使我们能够快速获得原本无法实现的观测能力。但是，并非每个团队都必须知道如何运行 Prometheus。我们正在研究如何使 Prometheus 尽可能自动化，以便团队可以专注于他们希望在服务和数据库上设置的查询和警报。

我们还创建了 Vulcan ，以便我们能够实现长期数据存储，同时保留我们已围绕其构建工具并培训人员如何使用的 Prometheus 查询语言。