ShuttleCloud 访谈

继续我们对 Prometheus 用户的一系列访谈，ShuttleCloud 讲述了他们如何开始使用 Prometheus。ShuttleCloud 的 Ignacio 还解释了 Prometheus 对初创公司的好处  在 2016 年 PromCon 上的演讲。

ShuttleCloud 做什么？

ShuttleCloud 是世界上最具可扩展性的电子邮件和联系人数据导入系统。我们帮助一些领先的电子邮件和地址簿提供商（包括 Google 和 Comcast）通过自动化数据导入的切换体验来增加用户增长和参与度。

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

通过为最终用户提供一个简单的迁移电子邮件的途径（同时让他们完全控制导入工具的用户界面），我们的客户可以显著提高用户激活率和入职体验。

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

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

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

最初，为我们的基础设施提供一个合适的监控系统并不是我们的主要关注点。那时我们的项目和实例数量不像现在这么多，所以我们使用其他简单的系统来在我们发现问题时发出警报并及时解决。

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

幸运的是，我们吸引了重要的客户，并且对服务水平协议（SLA）的要求也越来越高。因此，我们需要其他东西来衡量我们的性能并确保我们遵守所有 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" 的暂存环境的时间序列。
  • 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 收集器  功能导出的。我们在 Prometheus Alertmanager 上声明的第一个警报主要与上面提到的运行指标相关。

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

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

• operation_requests_total
• operation_statuses_total
• operation_errors_total

我们的大部分服务都复制在两个 Google Cloud Platform 可用区中。这包括监控系统。在两个或多个不同的区域中设置多个操作导出器非常简单，因为 Prometheus 可以聚合来自所有导出器的数据并生成一个指标（例如，所有导出器中的最大值）。目前我们没有高可用性的 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）。

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