在我们的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。
我们能够将新指标列入黑名单/白名单,但除了组织流程(很难更改/强制执行)之外,没有很好的方法来防范多话的服务。其他团队对当时可用的查询语言和可视化工具感到沮丧。我当时在和 Julius Volz 讨论推送与拉取指标系统,当我看到我可以真正控制我的 SLA 时,我就被说服想要尝试 Prometheus,因为我可以决定我要拉取什么以及频率。此外,我真的很喜欢查询语言。
你们是如何过渡的?
我们通过 Collectd 收集指标并发送到 OpenTSDB。与我们已运行的 Collectd 设置并行安装 Node Exporter 使我们能够开始尝试 Prometheus。我们还创建了一个自定义导出器来公开 Droplet 指标。很快,我们就拥有了与 OpenTSDB 服务相同的功能,并开始关闭 Collectd,然后关闭了 OpenTSDB 集群。
人们非常喜欢 Prometheus 和它附带的可视化工具。突然,我们这个小型指标团队有了做不完的积压工作,来不及让人们满意。于是,我们没有为人们的服务提供和维护 Prometheus,而是考虑创建工具,使其他团队尽可能轻松地运行他们自己的 Prometheus 服务器,并运行我们在公司使用的常见导出器。
一些团队已经开始使用 Alertmanager,但我们仍然有一种从现有监控工具中拉取 Prometheus 的概念。
自从切换以来,您看到了哪些改进?
我们改进了对虚拟机管理程序机器的洞察。我们从 Collectd 和 Node Exporter 中获取的数据大致相同,但是对于我们的 golang 开发人员团队来说,创建新的自定义导出器来公开特定于我们在每个虚拟机管理程序上运行的服务的数据要容易得多。
我们正在公开更好的应用程序指标。学习和教授如何创建 Prometheus 指标以便稍后正确聚合更容易。使用 Graphite,很容易创建一个稍后无法以某种方式聚合的指标,因为以点分隔的名称结构不正确。
创建警报比以前更快更简单,而且使用的语言也很熟悉。这使团队能够为他们了解和理解的服务创建更好的警报,因为他们可以快速迭代。
您认为 DigitalOcean 和 Prometheus 的未来会怎样?
我们正在继续研究如何使 DigitalOcean 的团队尽可能轻松地收集指标。目前,各个团队都在为他们关心的事物运行自己的 Prometheus 服务器,这使我们获得了原本无法如此快速获得的可见性。但是,并非每个团队都应该知道如何运行 Prometheus。我们正在研究如何使 Prometheus 尽可能自动化,以便团队可以专注于他们希望在服务和数据库上使用的查询和警报。
我们还创建了 Vulcan,以便我们拥有长期数据存储,同时保留我们围绕其构建工具并培训人们如何使用的 Prometheus 查询语言。