ShuttleCloud 访谈

继续我们的 Prometheus 用户访谈系列，ShuttleCloud 将谈谈他们是如何开始使用 Prometheus 的。来自 ShuttleCloud 的 Ignacio 还在 PromCon 2016 上讲解了 Prometheus 为什么适合小型初创公司 。

ShuttleCloud 是做什么的？

ShuttleCloud 是全球最具扩展性的电子邮件和联系人数据导入系统。我们帮助包括 Google 和 Comcast 在内的一些领先的电子邮件和通讯录供应商，通过自动化数据导入的切换体验来增加用户增长和活跃度。

通过将我们的 API 集成到他们的产品中，我们的客户可以让他们的用户轻松地将电子邮件和联系人从一个参与供应商迁移到另一个供应商，从而减少用户在切换到新供应商时面临的阻碍。支持的 24/7 电子邮件供应商包括所有主要的美国互联网服务供应商：Comcast、Time Warner Cable、AT&T、Verizon 等。

通过为终端用户提供简单的电子邮件迁移路径（同时保持对导入工具 UI 的完全控制），我们的客户显著提高了用户激活率和入驻体验。

ShuttleCloud 与 Google Gmail 平台的 集成 。 Gmail 已通过我们的 API 为 300 万用户导入了数据。

ShuttleCloud 的技术对处理导入所需的所有数据进行加密，此外还遵循最安全的标准（SSL、oAuth），以确保 API 请求的机密性和完整性。我们的技术使我们能够保证平台的高可用性，正常运行时间保证高达 99.5%。

在使用 Prometheus 之前，您的监控体验是怎样的？

起初，为我们的基础设施建立一个完善的监控系统并不是我们的主要优先事项。那时我们没有像现在这么多项目和实例，所以我们使用其他简单的系统，在出现问题时向我们发出警报并加以控制。

• 我们有一套自动脚本来监控机器的大部分运维指标。这些脚本基于 cron，通过 Ansible 从一台中央机器执行。警报是直接发送给整个开发团队的电子邮件。
• 我们信任 Pingdom 进行外部黑盒监控，并检查我们所有的前端是否正常运行。他们提供了简单的界面和警报系统，以防我们的任何外部服务无法访问。

幸运的是，大客户到来了，SLA 开始变得更加严格。因此，我们需要别的东西来衡量我们的表现，并确保我们遵守所有的 SLA。我们需要的功能之一是拥有关于绩效和业务指标的准确统计数据（例如，有多少迁移正确完成），所以当时我们考虑更多的是报表而不是监控。

我们开发了以下系统：

• 所有必要数据的来源是 CouchDB 中的状态数据库。在那里，每个文档代表一个操作的状态。这些信息由状态导入器（Status Importer）处理，并以关系型方式存储在 MySQL 数据库中。

• 一个组件从该数据库收集数据，并将信息聚合和后处理为多个视图。

  • 其中一个视图是电子邮件报表，这是我们出于报表目的所需的。该报表通过电子邮件发送。
  • 另一个视图将数据推送到仪表板，以便于控制。我们使用的仪表板服务是外部的。我们信任 Ducksboard，不仅因为仪表板易于设置且外观精美，还因为它们在达到阈值时提供自动警报。

随着项目数量的增加，我们很快意识到我们需要一个合适的指标、监控和警报系统。

我们当时所用系统的一些缺点包括：

• 没有集中的监控系统。每种指标类型都有不同的系统：
  • 系统指标 → 由 Ansible 运行的脚本。
  • 业务指标 → Ducksboard 和电子邮件报表。
  • 黑盒指标 → Pingdom。
• 没有标准的警报系统。每种指标类型都有不同的警报（电子邮件、推送通知等）。
• 某些业务指标没有警报。这些需要手动查看。

你们为什么决定研究 Prometheus？

我们分析了几个监控和警报系统。我们渴望亲自动手尝试，看看某种解决方案是成功还是失败。我们决定测试的系统是 Prometheus，原因如下：

• 首先，你不需要为了开始工作而定义一个固定的指标体系；指标可以在将来添加或更改。当你在还不确定所有想要监控的指标时，这提供了宝贵的灵活性。
• 如果你了解 Prometheus，你就会知道指标可以带有标签（labels），这使我们不必考虑处理不同的时间序列。这一点配合其查询语言，提供了更多的灵活性和强大的功能。例如，我们可以为不同的环境或项目定义相同的指标，并通过合适的标签获取特定的时间序列或聚合某些指标：
  • http_requests_total{job="my_super_app_1",environment="staging"} - 应用 "my_super_app_1" 在预发布环境对应的时间序列。
  • http_requests_total{job="my_super_app_1"} - 应用 "my_super_app_1" 在所有环境的时间序列。
  • http_requests_total{environment="staging"} - 所有任务在预发布环境的时间序列。
• Prometheus 支持用于服务发现的 DNS 服务。我们刚好已经有了一个内部 DNS 服务。
• 不需要安装任何外部服务（不像 Sensu，它需要像 Redis 这样的数据存储服务和像 RabbitMQ 这样的消息总线）。这虽然不是决定性因素，但它绝对使测试、部署和维护变得更加容易。
• Prometheus 的安装非常简单，因为你只需要下载一个可执行的 Go 文件。Docker 容器也运行良好，启动方便。

你们是如何使用 Prometheus 的？

最初我们只使用 node_exporter  开箱即用提供的一些指标，包括：

• 硬盘使用情况。
• 内存使用情况。
• 实例是否正常运行。

我们的内部 DNS 服务已集成用于服务发现，因此每个新实例都会被自动监控。

我们使用的一些 node_exporter 默认不提供的指标，是使用 node_exporter textfile collector  功能导出的。我们在 Prometheus Alertmanager 上声明的第一批警报主要与上述运维指标有关。

后来我们开发了一个操作导出器（operation exporter），使我们能够几乎实时地了解系统的状态。它暴露了业务指标，即所有操作的状态、迁入数量、完成的迁移数量以及错误数量。我们可以在 Prometheus 端聚合这些指标，并让它计算不同的速率。

我们决定导出并监控以下指标：

• operation_requests_total
• operation_statuses_total
• operation_errors_total

我们的大部分服务都在两个 Google Cloud Platform 可用区中进行副本部署。这也包括监控系统。在两个或更多不同的可用区中拥有多个操作导出器是非常直接的，因为 Prometheus 可以聚合来自所有导出器的数据并生成一个指标（例如，所有导出器的最大值）。目前我们的 Prometheus 或 Alertmanager 还没有实现高可用（HA）——只有一个元监控实例——但我们正在朝这个方向努力。

对于外部黑盒监控，我们使用 Prometheus Blackbox Exporter 。除了检查我们的外部前端是否正常运行外，它对于获取 SSL 证书过期日期的指标特别有用。它甚至会检查整个证书链。感谢 Robust Perception 在他们的 博文  中对此进行的完美解释。

我们在 Grafana 中设置了一些图表用于仪表板的可视化监控，与 Prometheus 的集成非常简单。用于定义图表的查询语言与 Prometheus 中的相同，这大大简化了它们的创建过程。

我们还将 Prometheus 与 Pagerduty 集成，并为关键警报创建了值班人员计划。对于那些不被认为是关键的警报，我们只发送电子邮件。

Prometheus 是如何让你们的情况变得更好的？

我们无法将 Prometheus 与我们之前的解决方案进行比较，因为我们之前没有类似的系统，但我们可以谈谈 Prometheus 对我们而言的亮点功能：

• 它的维护要求非常低。
• 它很高效：一台机器就能处理整个集群的监控。
• 社区非常友好——包括开发者和用户。此外，Brian 的博客  是一个非常好的资源。
• 它没有第三方依赖要求；只有服务器和导出器。（不需要维护 RabbitMQ 或 Redis。）
• Go 应用程序的部署轻而易举。

你认为 ShuttleCloud 和 Prometheus 的未来会怎样？

我们对 Prometheus 非常满意，但总是欢迎新的导出器（例如 Celery 或 Spark）。

每次我们添加新报警时都会面临一个问题：我们如何测试报警是否如预期工作？如果能有一种方法注入虚假指标来触发警报以便进行测试，那就太好了。