ShuttleCloud 访谈

继续我们对 Prometheus 用户进行的一系列访谈，ShuttleCloud 谈到了他们如何开始使用 Prometheus。来自 ShuttleCloud 的 Ignacio 还在 2016 年 PromCon 上解释了 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 进行外部黑盒监控，并检查我们所有的前端是否正常运行。他们提供了一个简单的界面和警报系统，以防我们的任何外部服务无法访问。

幸运的是，大客户来了，SLA 开始变得更加苛刻。因此，我们需要其他东西来衡量我们的表现，并确保我们遵守所有 SLA。我们需要的其中一项功能是拥有关于我们的性能和业务指标（即，有多少迁移正确完成）的准确统计数据，因此报告比监控更让我们关注。

我们开发了以下系统

Initial Shuttlecloud System

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

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

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

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

我们当时拥有的系统的一些缺点是

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

您为什么决定关注 Prometheus？

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

  • 首先，您不必定义固定的指标系统就可以开始使用它；指标可以在将来添加或更改。当您不知道您想要监控的所有指标时，这提供了宝贵的灵活性。
  • 如果您对 Prometheus 有任何了解，您就会知道指标可以有标签，这些标签使我们不必考虑不同的时间序列。这与其查询语言一起，提供了更大的灵活性和强大的工具。例如，我们可以为不同的环境或项目定义相同的指标，并获得特定的时间序列或使用适当的标签聚合某些指标
    • 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 不同，Sensu 需要像 Redis 这样的数据存储服务和像 RabbitMQ 这样的消息总线）。这可能不是一个决定性因素，但它肯定使测试更容易执行、部署和维护。
  • Prometheus 非常容易安装，因为您只需要下载一个可执行的 Go 文件。Docker 容器也运行良好，并且易于启动。

您如何使用 Prometheus？

最初，我们只使用 node_exporter 默认提供的一些指标，包括

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

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

我们使用的一些指标，默认情况下 node_exporter 不提供这些指标，是使用 node_exporter textfile collector 功能导出的。我们在 Prometheus Alertmanager 上声明的第一个警报主要与上述操作指标有关。

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

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

  • operation_requests_total
  • operation_statuses_total
  • operation_errors_total

Shuttlecloud Prometheus System

我们在两个 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）。

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