DigitalOcean 访谈
2016 年 9 月 14 日作者 Brian Brazil
在我们的 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 数据的概念。
切换后你们看到了哪些改进?
我们提升了对宿主机(hypervisor)的洞察力。虽然我们能从 Collectd 和 Node Exporter 获取的数据量差不多,但对于我们的 Go 语言开发团队来说,创建一个新的自定义 exporter 来暴露每台宿主机上运行的特定服务数据要容易得多。
我们正在暴露更好的应用指标。学习和教授如何创建一个能被正确聚合的 Prometheus 指标变得更容易了。而在 Graphite 中,很容易因为点分隔的名称结构不正确而创建一个之后无法以某种方式聚合的指标。
创建警报比我们以前的方式更快捷、更简单,而且使用的是一种熟悉的语言。这使得团队能够为他们了解和理解的服务创建更好的警报,因为他们可以快速迭代。
您认为 DigitalOcean 和 Prometheus 的未来会是怎样?
我们正在持续探索如何让 DigitalOcean 的团队尽可能轻松地收集指标。目前,各个团队都在为他们关心的服务运行自己的 Prometheus 服务器,这使我们获得了前所未有的快速可观测性。但是,并非每个团队都应该知道如何运行 Prometheus。我们正在研究如何使 Prometheus 尽可能自动化,以便团队只需专注于他们想要对其服务和数据库进行的查询和警报。
我们还创建了 Vulcan,以便拥有长期数据存储,同时保留我们已经围绕其构建工具并培训人们如何使用的 Prometheus 查询语言。