ShowMax 访谈

这是与 Prometheus 用户系列访谈的第二篇，旨在让他们分享评估和使用 Prometheus 的经验。

您能介绍一下自己和 ShowMax 的业务吗？

我是 Antonin Kral，负责 ShowMax 的研究和架构。在此之前，我担任了 12 年的架构师和 CTO 职务。

ShowMax 是一家订阅视频点播服务，于 2015 年在南非推出。我们拥有庞大的内容目录，包含 20,000 多集电视剧和电影。我们的服务目前在全球 65 个国家/地区可用。当知名竞争对手在美国和欧洲混战时，ShowMax 正在应对一个更棘手的问题：如何在撒哈拉以南非洲一个连接状况不佳的村庄里观看视频？全球已有 35% 的视频通过流媒体播放，但仍有许多地方尚未触及这场革命。

我们管理着大约 50 项服务，它们主要运行在围绕 CoreOS 构建的私有集群上。这些服务主要处理来自我们客户端（Android、iOS、AppleTV、JavaScript、Samsung TV、LG TV 等）的 API 请求，其中一些服务供内部使用。其中最大的内部管道之一是视频编码，在处理大量摄入批次时可以占用 400 多台物理服务器。

我们的大部分后端服务都使用 Ruby、Go 或 Python 编写。在用 Ruby 编写应用程序时，我们使用 EventMachine（MRI 上的 Goliath，JRuby 上的 Puma）。Go 通常用于需要大吞吐量且业务逻辑不多的应用程序。我们对使用 Python 编写的服务使用 Falcon 非常满意。数据存储在 PostgreSQL 和 ElasticSearch 集群中。我们使用 etcd 和自定义工具来配置 Varnish 以进行请求路由。

您在使用 Prometheus 之前的监控经验如何？

监控系统的主要用例是

• 主动监控和探测（通过 Icinga）
• 指标采集和基于这些指标创建告警（现在是 Prometheus）
• 从后端服务采集日志
• 从应用程序采集事件和日志

最后两个用例通过我们的日志基础设施处理。它包含一个在服务容器中运行的收集器，该收集器监听本地 Unix 套接字。应用程序使用该套接字向外部发送消息。消息通过 RabbitMQ 服务器传输到消费者。消费者是自定义编写的或基于 Heka 的。主要消息流之一是流向服务 ElasticSearch 集群，这使得 Kibana 和即席搜索可以访问日志。我们还将所有处理过的事件保存到 GlusterFS，用于归档和/或进一步处理。

我们曾经并行运行两个指标采集管道。第一个基于 Collectd + StatsD + Graphite + Grafana，另一个使用 Collectd + OpenTSDB。我们在这两个管道上都遇到了相当大的困难。我们不得不应对 Graphite 的 I/O 饥饿问题，或者 OpenTSDB 周围的复杂性和工具不足。

您为什么决定考虑使用 Prometheus？

从我们之前监控系统的问题中吸取教训后，我们开始寻找替代方案。只有少数解决方案进入了我们的候选名单。Prometheus 是最早入选的之一，因为当时我们的运维负责人 Jiri Brunclik 从 Google 的前同事那里得到了关于该系统的个人推荐。

概念验证非常顺利。我们很快就获得了一个可运行的系统。我们还评估了 InfluxDB 作为主系统以及 Prometheus 的长期存储。但由于最近的发展，这可能不再是我们可行的选择。

您是如何进行过渡的？

我们最初在其中一台服务服务器上使用 LXC 容器，但很快就转向了 Hetzner 的专用服务器，我们大部分服务都托管在那里。我们使用的是 PX70-SSD，配备 Intel® Xeon® E3-1270 v3 四核 Haswell 处理器和 32GB 内存，因此我们有足够的算力来运行 Prometheus。SSD 使我们能够将数据保留期设置为 120 天。我们的日志基础设施围绕着本地获取日志（在 Unix 套接字上接收它们）然后将其推送到各种工作节点而构建。

拥有这样的基础设施使得推送指标成为一个合乎逻辑的选择（特别是在 Prometheus 之前）。另一方面，Prometheus 主要围绕抓取指标的范式设计。我们希望保持一致，并最初将所有指标推送到 Prometheus。我们创建了一个名为 prometheus-pusher 的 Go 守护程序。它负责从本地导出器抓取指标并将其推送到 Pushgateway。推送指标有一些积极的方面（例如简化服务发现），但也存在不少缺点（例如难以区分网络分区和崩溃的服务）。我们已将 Prometheus-pusher 发布在 GitHub 上，您可以自行尝试。

下一步是我们要弄清楚如何管理仪表盘和图表。我们喜欢 Grafana 的集成，但不太喜欢 Grafana 管理仪表盘配置的方式。我们在 Docker 容器中运行 Grafana，因此任何更改都应该保留在容器外部。另一个问题是 Grafana 缺乏变更跟踪。

因此，我们决定编写一个生成器，它可以获取 git 中维护的 YAML 文件，并为 Grafana 仪表盘生成 JSON 配置。此外，它还能够将仪表盘部署到新启动的 Grafana 容器中，而无需将更改持久化到容器内部。这为您提供了自动化、可重复性和审计能力。

我们很高兴地宣布，该工具现已在 GitHub 上以 Apache 2.0 许可证发布。

切换后您看到了哪些改进？

我们立即看到的一个改进是 Prometheus 的稳定性。在此之前，我们一直在努力解决 Graphite 的稳定性和可扩展性问题，因此解决这个问题对我们来说是一个巨大的胜利。此外，Prometheus 的速度和稳定性使开发人员访问指标变得非常容易。Prometheus 确实帮助我们更好地拥抱了 DevOps 文化。

我们的后端开发人员之一 Tomas Cerevka 正在使用 JRuby 测试服务的新版本。他需要快速查看该特定服务的堆内存消耗。他能够迅速获取到这些信息。对我们来说，这种速度至关重要。

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

Prometheus 已成为 ShowMax 监控不可或缺的一部分，并且在可预见的未来将与我们同在。我们已将整个指标存储替换为 Prometheus，但摄取链仍基于推送。因此，我们正在考虑遵循 Prometheus 的最佳实践并切换到拉取模型。

我们也已经尝试过告警功能。我们希望在这个话题上投入更多时间，并制定出越来越复杂的告警规则。