ShowMax 访谈
2016年5月1日作者 Brian Brazil
这是关于 Prometheus 用户的一系列访谈中的第二篇，让用户分享他们评估和使用 Prometheus 的经验。
您可以介绍一下您自己以及 ShowMax 的业务吗？
我是 Antonin Kral，负责 ShowMax 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（Goliath on MRI，Puma on JRuby）。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，它配备了 Intel® Xeon® E3-1270 v3 四核 Haswell 处理器和 32GB RAM，因此我们有充足的算力来运行 Prometheus。SSD 允许我们将数据保留时间设置为 120 天。我们的日志基础设施围绕本地接收日志（通过 Unix 套接字接收）然后将其推送到各种工作节点而构建。
拥有这个基础设施使得推送指标成为一个合乎逻辑的选择（尤其是在 Prometheus 出现之前）。另一方面，Prometheus 主要围绕抓取指标的范例设计。我们最初希望保持一致，将所有指标推送到 Prometheus。我们创建了一个名为 prometheus-pusher 的 Go 守护进程。它负责从本地导出器抓取指标并将其推送到 Pushgateway。推送指标有一些优点（例如简化的服务发现），但也存在不少缺点（例如难以区分网络分区和崩溃的服务）。我们在 GitHub 上公开了 prometheus-pusher，您可以自行尝试。
下一步是确定如何管理仪表盘和图形。我们喜欢 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 的最佳实践，切换到拉取模型。
我们已经尝试过告警。我们希望在这个主题上投入更多时间，并制定越来越复杂的告警规则。