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) 的要求也越来越高。因此，我们需要其他方式来衡量我们的表现并确保我们遵守所有服务等级协议。我们所需的功能之一是获取关于我们性能和业务指标（例如，有多少迁移正确完成）的准确统计数据，因此报告比监控更受我们关注。

我们开发了以下系统

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

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

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

有了这些，我们很快就意识到，随着项目数量的增加，我们将需要一个完善的指标、监控和警报系统。

当时我们使用的系统存在一些缺点：

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

为什么决定考虑 Prometheus？

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

• 首先，你无需定义固定的指标系统即可开始使用它；指标可以在未来添加或更改。当你尚未明确所有要监控的指标时，这提供了宝贵的灵活性。
• 如果你了解 Prometheus，就会知道指标可以带有标签，这使我们不必考虑不同的时间序列。这一点，加上其查询语言，提供了更大的灵活性和强大的工具。例如，我们可以为不同的环境或项目定义相同的指标，并通过适当的标签获取特定的时间序列或聚合某些指标。
  • http_requests_total{job="my_super_app_1",environment="staging"} - 对应于应用程序“my_super_app_1”的 staging 环境的时间序列。
  • http_requests_total{job="my_super_app_1"} - 应用程序“my_super_app_1”所有环境的时间序列。
  • http_requests_total{environment="staging"} - 所有作业在所有 staging 环境的时间序列。
• Prometheus 支持 DNS 服务进行服务发现。我们碰巧已经有了一个内部 DNS 服务。
• 无需安装任何外部服务（例如，与 Sensu 不同，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 可以聚合所有数据并生成一个指标（即所有指标的最大值）。我们目前没有采用高可用 (HA) 配置的 Prometheus 或 Alertmanager——只有一个元监控实例——但我们正在为此努力。

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

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

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

Prometheus 如何让你们的工作变得更好？

我们无法将 Prometheus 与我们之前的解决方案进行比较，因为我们之前并没有一个完整的解决方案，但我们可以谈谈 Prometheus 对我们来说有哪些亮点功能：

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

ShuttleCloud 和 Prometheus 的未来会怎样？

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

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