这是 Prometheus 用户访谈系列的第二篇,旨在让用户分享他们评估和使用 Prometheus 的经验。
您能介绍一下自己以及 ShowMax 的业务吗?
我是 Antonin Kral,我负责 ShowMax 的研究和架构。在此之前,我在过去的 12 年里担任过架构师和首席技术官等职位。
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 通常用于需要大吞吐量且没有太多业务逻辑的应用程序。我们对使用 Falcon 编写的 Python 服务非常满意。数据存储在 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 从谷歌的前同事那里得到了关于该系统的个人推荐。
概念验证进展顺利。我们很快就获得了一个可用的系统。我们还评估了 InfluxDB 作为主要系统以及 Prometheus 的长期存储。但由于最近的发展,这可能不再是我们的可行选择。
您是如何过渡的?
我们最初从我们的一台服务服务器上的 LXC 容器开始,但很快转向了 Hetzner 的专用服务器,我们在那里托管了我们的大部分服务。我们使用的是 PX70-SSD,它是带有 32GB RAM 的 Intel® Xeon® E3-1270 v3 四核 Haswell,因此我们有足够的电源来运行 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 的最佳实践并切换到拉取模型。
我们还已经尝试过警报。我们希望花更多的时间在这个主题上,并提出越来越复杂的警报规则。