ShowMax 专访
2016年5月1日作者 Brian Brazil
这是与 Prometheus 用户系列访谈的第二篇，让他们分享评估和使用 Prometheus 的经验。
您能介绍一下您自己以及 ShowMax 的业务吗？
我是 Antonin Kral，负责 ShowMax 的研究和架构。在此之前，我在过去的12年里担任过架构师和CTO的角色。
ShowMax 是一项订阅式视频点播服务，于2015年在南非推出。我们拥有超过20,000集电视剧和电影的丰富内容库。我们的服务目前在全球65个国家提供。当更知名的竞争对手在美洲和欧洲进行小规模竞争时，ShowMax 正在解决一个更困难的问题：如何在撒哈拉以南非洲一个网络连接几乎不存在的村庄里刷剧？全球已经有35%的视频是流媒体播放，但仍有许多地方这场革命尚未触及。
我们管理着大约50项服务，主要运行在围绕 CoreOS 构建的私有集群上。它们主要处理来自我们客户端（Android、iOS、AppleTV、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 主要是围绕抓取（scrape）指标的范式设计的。我们最初想保持一致性，将所有指标都推送到 Prometheus。我们创建了一个名为 prometheus-pusher 的 Go 守护进程。它负责从本地导出器抓取指标，并将它们推送到 Pushgateway。推送指标有一些积极的方面（例如，简化的服务发现），但也有不少缺点（例如，难以区分网络分区和崩溃的服务）。我们已经在 GitHub 上提供了 Prometheus-pusher，所以您可以自己尝试。
下一步是决定使用什么来管理仪表盘和图表。我们喜欢 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 的最佳实践，切换到拉取（pull）模型。
我们已经尝试过警报功能。我们希望在这个主题上投入更多时间，并制定出越来越复杂的警报规则。