在对 Prometheus 用户进行系列访谈的过程中，Canonical 谈到了他们如何过渡到 Prometheus。
你能否介绍一下你自己以及 Canonical 是做什么的？
Canonical 最广为人知的可能是赞助 Ubuntu Linux 的公司。我们还生产或贡献了许多其他开源项目，包括 MAAS、Juju 和 OpenStack，并为这些产品提供商业支持。Ubuntu 为大多数 OpenStack 部署提供支持，在生产云中占 55%，在大型云部署中占 58%。
我的团队 BootStack 是我们的全托管私有云服务。我们为 Canonical 客户构建和运营 OpenStack 云。
在 Prometheus 之前，你们的监控经验是什么？
我们曾结合使用 Nagios、Graphite/statsd 和内部 Django 应用程序。这些工具无法为我们提供在内部和客户云环境中所需的灵活性和报告级别。
你们为什么决定关注 Prometheus？
我们评估了一些替代方案，包括 InfluxDB 和扩展我们对 Graphite 的使用，但我们最初使用 Prometheus 的体验证明它具有我们正在寻找的简洁性和强大功能的结合。我们特别欣赏标签的便利性、简单的 HTTP 协议以及开箱即用的 时序告警。Prometheus 有潜力用一个工具取代 2 个不同的工具（告警和趋势分析），这一点尤其吸引人。
此外，我们的一些员工在 Google 工作期间有使用 Borgmon 的经验，这极大地增加了我们的兴趣！
你们是如何过渡的？
我们仍处于过渡过程中，我们预计这将需要一些时间，因为我们需要在 Prometheus 中重新实现当前在现有系统中使用的许多自定义检查。最有用的资源是 prometheus.io 网站文档。
我们花了一段时间才选择导出器。我们最初选择了 collectd，但遇到了限制。我们现在正在编写一个 openstack-exporter，并且有点惊讶地发现没有一个好的、可用的从头开始编写导出器的示例。
我们遇到的一些挑战是：没有降采样支持，没有长期存储解决方案（尚未），并且我们对默认的 2 周保留期感到惊讶。目前还没有与 Juju 的集成，但我们正在努力！
自从切换以来，你们看到了哪些改进？
一旦我们掌握了导出器的使用方法，我们发现它们非常容易编写，并为我们提供了非常有用的指标。例如，我们正在为我们的云环境开发一个 openstack-exporter。我们还看到我们的 DevOps 和 WebOps 团队以及开发人员非常迅速地跨团队采用了它。我们还没有部署告警，但预计一旦我们进入过渡的这个阶段，将会看到更多。
你们认为 Canonical 和 Prometheus 的未来会怎样？
我们期望 Prometheus 成为我们监控和报告基础设施的重要组成部分，为当前和未来的众多系统提供指标收集和存储。我们认为它有可能取代 Nagios 作为告警工具。