DigitalOcean 访谈

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

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

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

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

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

你们为什么决定研究 Prometheus？

我对 OpenTSDB 感到沮丧，因为我负责保持集群的在线运行，但发现很难防止指标风暴。有时，一个团队会启动一个新的（非常啰嗦的）服务，这会影响集群的总容量并损害我的 SLA。

我们可以选择性地允许/阻止进入 OpenTSDB 的新指标，但除了组织流程（这很难改变/强制执行）之外，我们没有很好的方法来防止啰嗦的服务。其他团队对查询语言和当时可用的可视化工具感到沮丧。我曾与 Julius Volz 讨论过推送与拉取指标系统，当我看到我可以通过决定我拉取什么以及拉取频率来真正控制我的 SLA 时，我就想尝试 Prometheus 了。而且，我真的很喜欢它的查询语言。

你们是如何过渡的？

我们通过 Collectd 收集指标并发送到 OpenTSDB。在已经运行的 Collectd 设置并行安装 Node Exporter  使我们能够开始试验 Prometheus。我们还创建了一个自定义导出器来公开 Droplet 指标。很快，我们就实现了与 OpenTSDB 服务的特性对等，并开始关闭 Collectd，然后关闭 OpenTSDB 集群。

人们非常喜欢 Prometheus 及其附带的可视化工具。突然之间，我的小型指标团队的工作积压量大得让我们无法及时满足用户需求，与其为用户的服务提供和维护 Prometheus，我们转而研究创建工具，让其他团队尽可能轻松地运行自己的 Prometheus 服务器，并运行我们在公司使用的通用导出器。

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

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

我们改进了对虚拟机监控器（hypervisor）的洞察。从 Collectd 和 Node Exporter 中获得的数据大致相同，但我们 golang 开发团队更容易创建一个新的自定义导出器来公开运行在每个虚拟机监控器上的服务特有的数据。

我们正在公开更好的应用程序指标。更容易学习和教授如何创建 Prometheus 指标，这些指标以后可以正确聚合。对于 Graphite，很容易创建一个以后无法以某种方式聚合的指标，因为点分隔的名称结构不正确。

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

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

我们正在继续研究如何让 DigitalOcean 的团队尽可能轻松地收集指标。目前，团队正在为他们关心的内容运行自己的 Prometheus 服务器，这使我们能够获得否则无法快速获得的可见性。但是，并非所有团队都应该知道如何运行 Prometheus。我们正在研究如何让 Prometheus 尽可能自动化，以便团队可以专注于他们想要在其服务和数据库上运行的查询和警报。

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