Canonical 访谈

在我们的 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 的示例。

我们遇到的一些挑战包括：没有降采样支持，没有长期存储解决方案（目前），以及我们对默认的两周保留期感到惊讶。目前还没有与 Juju 的集成，但 我们正在努力！

切换后你们看到了哪些改进？

一旦我们掌握了 exporter，我们发现它们非常容易编写，并且为我们提供了非常有用的指标。例如，我们正在为我们的云环境开发一个 openstack-exporter。我们还看到 DevOps 和 WebOps 团队以及开发人员之间迅速实现了跨团队采用。我们还没有设置告警，但一旦我们进入过渡的这个阶段，预计会有更多进展。

您认为 Canonical 和 Prometheus 的未来会怎样？

我们期望 Prometheus 成为我们监控和报告基础设施的重要组成部分，为众多现有和未来的系统提供指标收集和存储。我们认为它有潜力取代 Nagios 作为告警工具。