ShowMax 专访

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

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

我是 Antonin Kral，在 ShowMax 负责研究与架构。在此之前，我在过去 12 年里一直担任架构师和 CTO 的职位。

ShowMax 是一项订阅式视频点播服务，于 2015 年在南非推出。我们拥有超过 20,000 集电视剧和电影的丰富内容库。我们的服务目前已在全球 65 个国家/地区提供。当那些更知名的竞争对手还在欧美市场激烈竞争时，ShowMax 正在努力解决一个更棘手的问题：在撒哈拉以南非洲地区一个网络连接几乎不存在的村庄里，如何实现“刷剧”？全球已经有 35% 的视频是通过流媒体播放的，但仍有许多地方被这场技术革命所忽略。

我们管理着大约 50 项服务，它们大多运行在基于 CoreOS 构建的私有集群上。这些服务主要处理来自我们客户端（Android、iOS、Apple TV、JavaScript、三星电视、LG 电视等）的 API 请求，其中一些服务则供内部使用。我们最大的内部处理流程之一是视频编码，在处理大批量内容注入时，它会占用 400 多台物理服务器。

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

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

监控系统的主要用例是：

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

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

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

你们为什么决定研究 Prometheus？

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

概念验证进行得非常顺利。我们很快就搭建起了一个可用的系统。我们还评估了 InfluxDB 作为主要系统以及 Prometheus 的长期存储方案。但由于最近的一些发展，这可能不再是我们的一个可行选项了。

你们是如何过渡的？

我们最初是在一台服务服务器上使用 LXC 容器开始的，但很快就转移到了一台来自 Hetzner 的专用服务器上，我们的大部分服务都托管在那里。我们使用的是 PX70-SSD，配备了英特尔® 至强® E3-1270 v3 四核 Haswell 处理器和 32GB 内存，所以我们有足够的能力来运行 Prometheus。SSD 让我们能够将数据保留时间设置为 120 天。我们的日志基础设施是围绕在本地获取日志（通过 Unix 套接字接收），然后将它们推送到各个工作进程来构建的。

有了这个基础设施，推送指标成了一个合乎逻辑的选择（尤其是在使用 Prometheus 之前）。另一方面，Prometheus 主要是围绕拉取指标的模式设计的。我们最初希望保持一致性，将所有指标都推送到 Prometheus。为此，我们创建了一个名为 prometheus-pusher 的 Go 守护进程。它负责从本地的 exporter 中拉取指标，并将它们推送到 Pushgateway。推送指标有一些积极的方面（例如，简化了服务发现），但也有不少缺点（例如，难以区分是网络分区还是服务崩溃）。我们将 Prometheus-pusher 发布在了 GitHub 上，您可以亲自尝试。

下一步是决定使用什么来管理仪表盘和图表。我们喜欢 Grafana 的集成，但不太喜欢 Grafana 管理仪表盘配置的方式。我们在 Docker 容器中运行 Grafana，所以任何更改都应该保留在容器之外。另一个问题是 Grafana 缺乏变更追踪功能。

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

我们很高兴地宣布，这个工具现在也以 Apache 2.0 许可证在 GitHub 上提供。

切换后你们看到了哪些改进？

我们立即看到的一个改进是 Prometheus 的稳定性。在此之前，我们一直在与 Graphite 的稳定性和可扩展性作斗争，所以解决了这个问题对我们来说是一个巨大的胜利。此外，Prometheus 的速度和稳定性让开发人员能够非常轻松地访问指标。Prometheus 真的在帮助我们拥抱 DevOps 文化。

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

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

Prometheus 已经成为 ShowMax 监控中不可或缺的一部分，并且在可预见的未来将继续伴随我们。我们已经用 Prometheus 替换了我们整个的指标存储系统，但数据采集链仍然是基于推送的。因此，我们正在考虑遵循 Prometheus 的最佳实践，切换到拉取模式。

我们已经尝试过使用警报功能。我们希望在这个主题上投入更多时间，并设计出越来越复杂的警报规则。