DigitalOcean 采访

在我们的 Prometheus 用户访谈系列中，DigitalOcean 讲述了他们如何使用 Prometheus。Carlos Amedee 还在 2016 年 PromCon 大会上谈到了部署的社会方面。

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

我叫 Ian Hansen，在平台指标团队工作。DigitalOcean 提供简单的云计算服务。迄今为止，我们已在 13 个区域创建了 2000 万个 Droplets（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。我们还创建了一个自定义 exporter 来暴露 Droplet 指标。很快，我们就实现了与 OpenTSDB 服务的相同功能，并开始关闭 Collectd，然后关闭了 OpenTSDB 集群。

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

一些团队已经开始使用 Alertmanager，但我们仍然保留着将 Prometheus 数据集成到现有监控工具中的理念。

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

我们提高了对宿主机（hypervisor）的洞察力。我们从 Collectd 和 Node Exporter 中获得的数据量大致相同，但对于我们的 Go 语言开发者团队来说，创建一个新的自定义 exporter 以暴露每个宿主机上运行的服务特有的数据要容易得多。

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

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

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

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

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