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 与 Gmail 的集成 ShuttleCloud 与 Google Gmail 平台的集成。 Gmail 已通过我们的 API 为 300 万用户导入了数据。

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

ShuttleCloud by Numbers

在使用 Prometheus 之前，你们的监控经验是怎样的？

起初，为我们的基础设施建立一个完善的监控系统并不是我们的主要优先事项之一。当时我们没有现在这么多项目和实例，所以我们使用其他简单的系统来提醒我们是否有异常，以便进行控制。

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

幸运的是，大客户来了，SLA 也开始变得更加严格。因此，我们需要其他方法来衡量我们的表现，并确保我们符合所有 SLA。我们需要的一个功能是获取关于我们的性能和业务指标（即有多少迁移成功完成）的准确统计数据，所以报告比监控更受我们关注。

我们开发了以下系统

Initial Shuttlecloud System

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

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

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

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

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

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

你们为什么决定考虑使用 Prometheus？

我们分析了几种监控和告警系统。我们渴望亲自动手，看看某个解决方案是成功还是失败。我们决定测试的系统是 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"} - 对应于所有 job 在所有 staging 环境的时间序列。
  • Prometheus 支持使用 DNS 服务进行服务发现。我们恰好已经拥有一个内部 DNS 服务。
  • 无需安装任何外部服务（与 Sensu 不同，例如，Sensu 需要像 Redis 这样的数据存储服务和像 RabbitMQ 这样的消息总线）。这可能不是决定性因素，但它确实使测试更容易执行、部署和维护。
  • Prometheus 安装非常容易，只需下载一个可执行的 Go 文件即可。Docker 容器也运行良好，很容易启动。

你们如何使用 Prometheus？

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

  • 硬盘使用情况。
  • 内存使用情况。
  • 实例是否启动或关闭。

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

我们使用的一些指标，node_exporter 默认不提供，是通过 node_exporter textfile collector 功能导出的。我们在 Prometheus Alertmanager 上声明的第一个告警主要与上述运行指标相关。

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

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

  • operation_requests_total
  • operation_statuses_total
  • operation_errors_total

Shuttlecloud Prometheus System

我们的绝大多数服务都在两个 Google Cloud Platform 可用区进行了冗余部署。这包括监控系统。在两个或多个不同的可用区部署多个操作 exporter 是很简单的，因为 Prometheus 可以聚合所有这些数据并生成一个指标（即取最大值）。我们目前没有对 Prometheus 或 Alertmanager 进行高可用（HA）部署——只有一个元监控实例——但我们正在努力实现。

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

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

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

Prometheus 如何改善了你们的工作？

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

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

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

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

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