在我们的 Prometheus 用户采访系列中，iAdvize 的 Laurent COMMARIEU 谈论了他们如何用 Prometheus 替换旧有的 Nagios 和 Centreon 监控系统。
您能介绍一下 iAdvize 的业务吗？
我是 Laurent COMMARIEU，iAdvize 的一名系统工程师。我在拥有 60 人的研发部门工作，我们的团队由 5 名系统工程师组成。我们的主要工作是确保应用程序、服务和底层系统正常运行。我们与开发人员合作，确保他们的代码能够以最简单的方式上线生产环境，并在每个步骤提供必要的反馈。这就是监控的重要性所在。
iAdvize 是一个全栈的对话式商务平台。我们为品牌提供了一种便捷的方式，使其能够集中地与客户互动，无论客户通过何种沟通渠道（聊天、电话、视频、Facebook 主页、Facebook Messenger、Twitter、Instagram、WhatsApp、短信等）。我们的客户遍及电商、银行、旅游、时尚等行业，遍及 40 个国家。我们是一家拥有 200 名员工的跨国公司，在法国、英国、德国、西班牙和意大利设有办事处。我们在 2015 年筹集了 1600 万美元。
在使用 Prometheus 之前，你们的监控经验如何？
我于 2016 年 2 月加入 iAdvize。之前我曾在专注于网络和应用监控的公司工作。我们使用过像 Nagios、Cacti、Centreon、Zabbix、OpenNMS 等开源软件，也用过一些非免费软件，例如 HP NNM、IBM Netcool 套件、BMC Patrol 等。
iAdvize 过去将监控工作委托给外部供应商。他们使用 Nagios 和 Centreon 提供 24/7 全天候监控。这套工具集在旧的静态架构（裸机服务器，没有虚拟机，没有容器）下运行良好。为了完善这个监控栈，我们还使用了 Pingdom。
随着我们将单体应用转向微服务架构（使用 Docker），以及我们将当前工作负载迁移到基础设施云提供商的意愿，我们需要对监控拥有更多的控制权和灵活性。与此同时，iAdvize 招聘了 3 个人，将基础设施团队从 2 人增加到 5 人。使用旧系统时，将新的指标添加到 Centreon 至少需要几天或一周时间，并且花费了真实的成本（时间和金钱）。
你们为什么决定考虑使用 Prometheus？
我们知道 Nagios 等工具不是一个好的选择。Prometheus 当时是一颗冉冉升起的新星，我们决定对其进行 PoC（概念验证）。起初也将 Sensu 列入考虑范围，但 Prometheus 对我们的用例来说似乎更有前景。
我们需要一种能够与我们的服务发现系统 Consul 集成的工具。我们的微服务已经有了 /health 路由；添加一个 /metrics 端点很简单。对于我们使用的几乎所有工具，都有可用的 Exporter（MySQL、Memcached、Redis、nginx、FPM 等）。
理论上看起来不错。
你们是如何进行迁移的？
首先，我们必须说服开发团队（40人），Prometheus 是适合这项工作的工具，并且他们必须为自己的应用程序添加 Exporter。所以我们在 RabbitMQ 上做了一个小演示，安装了一个 RabbitMQ Exporter 并构建了一个简单的 Grafana 看板来向开发人员展示使用指标。还编写了一个 Python 脚本来创建一些队列并发布/消费消息。
他们对看到队列和消息实时出现感到非常惊讶。在此之前，开发人员无法访问任何监控数据。Centreon 受限于我们的基础设施提供商。如今，iAdvize 的每个人都可以使用 Grafana，通过 Google Auth 集成进行身份验证。目前有 78 个活跃账户（从开发团队到 CEO）。
在使用 Consul 和 cAdvisor 开始监控现有服务后，我们监控了容器的实际存在情况。之前使用 Pingdom 检查进行监控，但这还不够。
我们用 Go 开发了一些自定义的 Exporter，用于从我们的数据库（MySQL 和 Redis）中抓取一些业务指标。
很快，我们就能够用 Prometheus 替换掉所有旧有的监控系统了。
切换后你们看到了哪些改进？
业务指标变得非常受欢迎，销售期间每个人都会连接到 Grafana 查看我们是否能打破记录。我们监控同时对话数、路由错误、在线客服数量、加载 iAdvize 标签的访客数量、API 网关调用次数等。
我们花了一个月的时间，基于 Newrelic Exporter 和 用于 Grafana 的 Percona 看板 进行分析，优化了我们的 MySQL 服务器。这是个巨大的成功，让我们发现了效率低下的地方并进行了优化，将数据库大小减少了 45%，高峰延迟降低了 75%。
还有很多可以说的。我们知道 AMQP 队列是否有消费者，或者它是否正在异常填充。我们知道容器何时重启。
可见性简直太棒了。
这只是针对旧平台的改进。
越来越多的微服务将部署在云端，而 Prometheus 被用于监控它们。我们使用 Consul 注册服务，使用 Prometheus 发现指标路由。一切都运转得非常顺利，我们能够构建一个包含大量关键业务、应用和系统指标的 Grafana 看板。
我们正在构建一个可扩展的架构，使用 Nomad 来部署我们的服务。Nomad 会在 Consul 中注册健康的服务，通过一些标签重贴（relabeling），我们能够过滤出带有 "metrics=true" 标签的服务。这极大地节省了我们部署监控的时间。我们什么都不用做 ^^。
我们还使用了 EC2 服务发现。这对于自动伸缩组非常有用。我们伸缩和回收实例，并且它们已经受到监控。再也不用等待我们的外部基础设施提供商注意到生产环境中发生的情况了。
我们使用 Alertmanager 通过短信或发送警报到我们的 Flowdock。
您认为 iAdvize 和 Prometheus 的未来前景如何？
- 我们正在等待一种简单的方式来为我们的容量规划添加一个长期可扩展的存储方案。
- 我们梦想有一天，我们的自动伸缩能够由 Prometheus 警报触发。我们希望构建一个基于响应时间和业务指标的自主系统。
- 我曾使用过 Netuitive，它具有出色的异常检测和自动关联功能。如果在 Prometheus 中也能有这些功能就太好了。