DigitalOcean 访谈

在我们的 Prometheus 用户系列访谈中，下一位是 DigitalOcean，他们将讲述如何使用 Prometheus。Carlos Amedee 也在 PromCon 2016 上谈到了推广过程中的社会性因素 。

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

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

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

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

你们为什么决定研究 Prometheus？

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

我们能够对进入 OpenTSDB 的新指标设置黑白名单，但除了依靠组织流程（这很难改变/强制执行）外，没有很好的方法来防范那些“话痨”服务。其他团队对当时的查询语言和可用的可视化工具感到不满。我曾和 Julius Volz 聊过推（push）与拉（pull）的指标系统，当我看到我可以通过决定拉取什么以及拉取频率来真正控制我的 SLA 时，我便下定决心要尝试 Prometheus。此外，我真的非常喜欢它的查询语言。

你们是如何过渡的？

我们过去是通过 Collectd 发送指标到 OpenTSDB 来收集指标的。在我们已运行的 Collectd 设置旁并行安装 Node Exporter  让我们能够开始试验 Prometheus。我们还创建了一个自定义的 exporter 来暴露 Droplet 的指标。很快，我们的功能就与 OpenTSDB 服务相当，于是我们开始关闭 Collectd，然后关闭了 OpenTSDB 集群。

大家都很喜欢 Prometheus 及其附带的可视化工具。突然之间，我们这个小小的指标团队积压的工作多到无法及时完成来满足大家的需求。我们不再为人们的服务提供和维护 Prometheus，而是转而考虑创建工具，让其他团队尽可能轻松地运行自己的 Prometheus 服务器，并运行公司通用的 exporter。

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

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

我们提升了对宿主机的洞察力。我们能从 Collectd 和 Node Exporter 中获得的数据大致相同，但对于我们的 Golang 开发团队来说，创建一个新的自定义 exporter 来暴露每台宿主机上运行的特定服务的数据要容易得多。

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

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

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

我们正持续探索如何让 DigitalOcean 的团队尽可能轻松地收集指标。目前，各个团队都在为他们关心的事物运行自己的 Prometheus 服务器，这让我们能够以更快的速度获得我们原本无法获得的可观测性。但是，并非每个团队都应该知道如何运行 Prometheus。我们正在研究如何让 Prometheus 尽可能自动化，以便团队只需专注于他们想要对其服务和数据库进行的查询和警报。

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