iAdvize 访谈
2017年5月17日作者 Brian Brazil
在我们的 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 被我们的基础设施提供商限制了。今天，Grafana 对 iAdvize 的每一个人开放，并集成了 Google Auth 进行身份验证。目前上面有 78 个活跃账户（从开发团队到 CEO 都有）。
在我们开始使用 Consul 和 cAdvisor 监控现有服务后，我们还监控了容器的实际存在情况。此前它们仅通过 Pingdom 检查进行监控，但这远远不够。
我们用 Go 语言开发了一些自定义 Exporter，以从我们的数据库（MySQL 和 Redis）中抓取业务指标。
很快，我们就能用 Prometheus 取代所有旧的监控系统了。
切换后你们看到了哪些改进？
业务指标变得非常受欢迎，在销售旺季，每个人都会连接到 Grafana 查看我们是否创下了新纪录。我们监控同时进行的对话数量、路由错误、已连接的坐席、加载 iAdvize 标签的访客数量、对 API 网关的调用等。
我们花了一个月时间，基于 Newrelic Exporter 和 [Percona Grafana 仪表板] (https://github.com/percona/grafana-dashboards ) 进行分析，对我们的 MySQL 服务器进行了优化。这取得了真正的成功，使我们能够发现效率低下的问题，并执行优化，从而将数据库规模缩减了 45%，峰值延迟降低了 75%。
可以说的事情还有很多。如果一个 AMQP 队列没有消费者，或者它异常填充，我们都能知道。我们甚至能知道容器何时重启。
这种可见性简直太棒了。
这还只是针对旧平台的情况。
越来越多的微服务正在云端部署，Prometheus 也被用来监控它们。我们使用 Consul 注册服务，并利用 Prometheus 来发现指标路由。一切运行良好，我们能够构建包含大量关键业务、应用和系统指标的 Grafana 仪表板。
我们正在构建一个可扩展的架构，利用 Nomad 来部署服务。Nomad 将健康的服务注册到 Consul 中，通过一些标签重写（relabeling），我们可以过滤出标记为 "metrics=true" 的服务。这为我们部署监控节省了大量时间。我们几乎什么都不用做 ^^。
我们还使用了 EC2 服务发现功能。这对于自动伸缩组非常有用。我们进行伸缩和回收实例，它们会自动被监控。再也不用等待我们的外部基础设施提供商来察觉生产环境中发生了什么了。
我们使用 alertmanager 通过短信或发送到我们的 Flowdock 发送一些警报。
你认为 iAdvize 和 Prometheus 的未来会怎样？
- 我们正在期待一种简单的方法来增加长期可扩展的存储，以便进行容量规划。
- 我们有一个梦想，希望有一天我们的自动伸缩能够由 Prometheus 警报触发。我们想要建立一个基于响应时间和业务指标的自治系统。
- 我过去曾使用过 Netuitive ，它具有出色的异常检测功能和自动关联功能。如果 Prometheus 能具备这些功能就太棒了。