在我们 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。 我们还创建了一个自定义 exporter 来公开 Droplet 指标。 不久，我们拥有了与 OpenTSDB 服务相同的功能，并开始关闭 Collectd，然后关闭了 OpenTSDB 集群。
人们非常喜欢 Prometheus 以及随之而来的可视化工具。 突然，我的小型指标团队积压了大量工作，我们无法及时完成以满足人们的需求。 因此，我们没有为人们的服务提供和维护 Prometheus，而是考虑创建工具，使其他团队尽可能轻松地运行自己的 Prometheus 服务器，并运行我们在公司使用的通用 exporters。
一些团队已经开始使用 Alertmanager，但我们仍然有从我们现有的监控工具中拉取 Prometheus 的概念。
自切换以来，您看到了哪些改进？
我们改进了对 hypervisor 机器的洞察。 我们从 Collectd 和 Node Exporter 获取的数据大致相同，但对于我们的 golang 开发者团队来说，创建新的自定义 exporter 来公开特定于我们在每个 hypervisor 上运行的服务的数据要容易得多。
我们正在公开更好的应用程序指标。 学习和教授如何创建可以在以后正确聚合的 Prometheus 指标更容易。 使用 Graphite，很容易创建一个以后无法以某种方式聚合的指标，因为点分隔的名称结构不正确。
创建警报比我们以前的方式更快更简单，而且使用的语言也很熟悉。 这使团队能够为他们了解和理解的服务创建更好的警报，因为他们可以快速迭代。
您认为 DigitalOcean 和 Prometheus 的未来会怎样？
我们正在继续研究如何使 DigitalOcean 的团队尽可能轻松地收集指标。 目前，团队正在为他们关心的事物运行自己的 Prometheus 服务器，这使我们能够比以往更快地获得可观察性。 但是，并非每个团队都必须知道如何运行 Prometheus。 我们正在研究如何使 Prometheus 尽可能自动化，以便团队可以专注于他们希望在其服务和数据库上进行的查询和警报。
我们还创建了 Vulcan，以便我们拥有长期数据存储，同时保留我们围绕其构建工具并培训人们如何使用的 Prometheus 查询语言。