继续我们对 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 有潜力用一个工具取代两个不同的工具（告警和趋势分析），这一点尤其吸引人。
此外，我们的一些员工在 Google 工作期间有使用 Borgmon 的经验，这大大增加了我们的兴趣！
您是如何过渡的？
我们目前仍在过渡过程中，由于我们在现有系统中使用了大量自定义检查，需要将它们在 Prometheus 中重新实现，预计这将需要一些时间。最有用的资源是 prometheus.io 网站的文档。
我们花了一些时间选择 exporter。最初我们使用了 collectd，但遇到了限制。我们现在正在编写一个 openstack-exporter，并且有点惊讶地发现，没有一个好的、可用的从头编写 exporter 的示例。
我们遇到的一些挑战包括：没有下采样支持，没有长期存储解决方案（目前），以及默认的 2 周保留期让我们感到惊讶。目前还没有与 Juju 的集成，但我们正在努力！
切换后，您看到了哪些改进？
一旦我们掌握了 exporter 的用法，就发现它们很容易编写，并且为我们提供了非常有用的指标。例如，我们正在为我们的云环境开发一个 openstack-exporter。我们也看到了 DevOps 和 WebOps 团队以及开发人员非常迅速的跨团队采纳。我们尚未部署告警功能，但预计一旦进入过渡的这一阶段，将会看到更多进展。
您认为 Canonical 和 Prometheus 的未来会怎样？
我们预计 Prometheus 将成为我们监控和报告基础设施的重要组成部分，为众多当前和未来系统提供指标收集和存储。我们认为它有可能取代 Nagios 进行告警。