iAdvize 专访

本系列将继续介绍 Prometheus 的用户。iAdvize 的 Laurent COMMARIEU 讲述了他们如何用 Prometheus 取代了传统的 Nagios 和 Centreon 监控系统。

您能介绍一下 iAdvize 的业务吗？

我是 Laurent COMMARIEU，iAdvize 的一名系统工程师。我在 60 人的研发部门工作，是 5 名系统工程师团队的一员。我们的主要工作是确保应用程序、服务和底层系统正常运行。我们与开发人员合作，为他们的代码提供最便捷的上线路径，并在每个阶段提供必要的反馈。这就是监控的重要性所在。

iAdvize 是一个全栈会话式商务平台。我们提供了一种简单的方式，让品牌能够集中与客户互动，无论通过何种沟通渠道（聊天、电话、视频、Facebook Pages、Facebook Messenger、Twitter、Instagram、WhatsApp、SMS 等）。我们的客户遍布 电子商务、银行、旅游、时尚等领域，覆盖 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 端点很简单。对于我们使用的几乎所有工具，都有相应的导出器可用（MySQL、Memcached、Redis、nginx、FPM 等）。

纸面上看起来不错。

你们是如何过渡的？

首先，我们必须说服开发团队（40 人），让他们相信 Prometheus 是合适的工具，并且他们必须为他们的应用程序添加导出器。于是，我们对 RabbitMQ 进行了演示，安装了 RabbitMQ 导出器，并构建了一个简单的 Grafana  仪表板来向开发人员展示使用情况指标。我们编写了一个 Python 脚本来创建队列并发布/消耗消息。

当他们看到队列和消息实时显示时，他们非常惊讶。在此之前，开发人员无法访问任何监控数据。Centreon 的访问权限受到我们基础设施提供商的限制。今天，iAdvize 的每个人都可以使用 Grafana，通过 Google 身份验证进行登录。上面有 78 个活跃账户（从开发团队到 CEO）。

在通过 Consul 和 cAdvisor 监控现有服务后，我们监控了容器的实际存在情况。之前是通过 Pingdom 检查来监控，但这还不够。

我们用 Go 开发了几个自定义导出器，用于从我们的数据库（MySQL 和 Redis）抓取一些业务指标。

很快，我们就能够用 Prometheus 替换所有传统的监控。

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

业务指标变得非常受欢迎，在销售旺季，每个人都会连接到 Grafana 查看我们是否会创下某些记录。我们监控同时进行的对话数量、路由错误、已连接的座席、加载 iAdvize 标签的访问者数量、API 网关上的调用次数等等。

我们花了一个月的时间，基于 Newrelic 导出器  和 [Percona 的 Grafana 仪表板] (https://github.com/percona/grafana-dashboards ) 进行分析，以优化我们的 MySQL 服务器。这是一次真正的成功，使我们能够发现效率低下之处并进行优化，从而将数据库大小减少了 45%，并将峰值延迟降低了 75%。

有很多东西可以讲。我们知道 AMQP 队列是否没有消费者，或者它是否在异常填充。我们知道容器何时重启。

可见性太棒了。

这仅仅是针对传统平台。

越来越多的微服务将被部署到云端，Prometheus 用于监控它们。我们使用 Consul 注册服务，并使用 Prometheus 发现指标路由。一切都很顺利，我们能够构建一个包含大量关键业务、应用程序和系统指标的 Grafana 仪表板。

我们正在构建一个可扩展的架构，使用 Nomad  来部署我们的服务。Nomad 将健康的服务注册到 Consul，通过一些标签重写，我们可以筛选出带有 "metrics=true" 标签的服务。这为我们部署监控节省了大量时间。我们什么都不用做 ^^。

我们还使用 EC2 服务发现。对于自动伸缩组来说，这非常有用。我们伸缩和回收实例，它们已经得到监控。不再需要等待我们的外部基础设施提供商注意到生产环境中发生的事情。

我们使用 alertmanager 通过 SMS 发送警报，或发送到我们的 Flowdock 。

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

• 我们正在等待一种简单的方法来为我们的容量规划添加长期可扩展的存储。
• 我们有一个梦想，有一天，我们的自动伸缩将由 Prometheus 警报触发。我们希望构建一个基于响应时间和业务指标的自主系统。
• 我曾与 Netuitive  合作过，它有一个很棒的异常检测功能，并能自动关联。如果在 Prometheus 中也能有这样的功能就好了。