这是 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 和自定义工具来配置 Varnishes 以进行请求路由。
您在使用 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 的最佳实践并切换到拉取模型。
我们还已经尝试过警报。我们希望花更多时间在这个主题上，并提出越来越复杂的警报规则。