JustWatch 访谈

我们继续对 Prometheus 用户的系列访谈，本期 JustWatch 将讲述他们是如何建立监控系统的。

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

对于消费者而言，JustWatch  是一个流媒体搜索引擎，帮助用户在 17 个国家/地区找到合法在线观看和影院上映的电影和电视节目。您可以在所有主流媒体提供商（如 Netflix、HBO、Amazon Video、iTunes、Google Play 等）中搜索电影内容。

对于我们的客户，如电影制片厂或视频点播提供商，我们是一家国际电影营销公司。我们从消费者应用程序中收集关于全球影迷购买行为和电影品味的匿名数据。我们帮助制片厂向正确的目标受众宣传其内容，并通过最大限度地减少无效覆盖，使数字视频广告的效率大大提高。

自 2014 年推出以来，我们在没有花费一分钱营销费用的情况下，从零发展成为全球前 2 万的大型网站之一，在不到两年的时间里成为全球最大的流媒体搜索引擎。目前，我们仅有 10 人的工程师团队，构建并运营着一个完全 Docker 化的技术栈，包含约 50 个微服务和宏服务，大部分运行在 Kubernetes  上。

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

在之前的公司，我们很多人都使用过市面上大多数开源监控产品。我们有相当丰富的使用 Nagios 、Icinga 、Zabbix 、Monit 、Munin 、Graphite  以及其他一些系统的经验。我曾在一家公司帮助用 Puppet 构建了一个分布式的 Nagios 系统。这个系统很好，因为新服务会自动出现在系统中，但移除实例仍然很痛苦。一旦你的系统中有了一些变化，基于主机和服务的监控套件就不是很适用了。Prometheus 采用的基于标签的方法是我一直想要但之前没有找到的。

你们为什么决定研究 Prometheus？

在 JustWatch，Prometheus 的公开发布恰逢其时。在公司成立的头几个月，我们主要进行黑盒监控——使用 CloudWatch  监控一些最重要的内部指标，并结合 Pingdom  等外部服务来检测全站范围的中断。此外，那些传统基于主机的解决方案没有一个能让我们满意。在一个充满容器和微服务的世界里，像 Icinga、Thruk  或 Zabbix 这样基于主机的工具感觉已经过时，无法胜任这项工作。当我们开始研究白盒监控时，幸运的是我们的一些人参加了 Golang Meetup，Julius 和 Björn 在那里宣布了 Prometheus。我们迅速搭建了一个 Prometheus 服务器，并开始对我们的 Go 服务进行插桩（我们的后端几乎只用 Go）。这过程非常简单，令人惊叹——它的设计感觉就像把云和服务导向作为第一原则，并且从不碍事。

你们是如何过渡的？

过渡并不难，因为从时间点上看，我们很幸运能从没有像样的监控直接过渡到 Prometheus。

向 Prometheus 的过渡主要是将 Go 客户端集成到我们的应用中，并包装 HTTP 处理程序。我们还编写并部署了几个 exporter，包括 node_exporter  和几个用于云提供商 API 的 exporter。根据我们的经验，监控和告警是一个永无止境的项目，但大部分工作是在几周内作为一个副项目完成的。

自从部署了 Prometheus，每当我们遗漏了什么或者从头设计新服务时，我们都会倾向于查看指标。

我们花了一些时间才完全掌握 PromQL 和标签概念的精妙之处，但这些努力确实物有所值。

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

Prometheus 让我们豁然开朗，它使得从白盒监控和基于标签的金丝雀部署中获益变得异常简单。许多 Golang 方面的开箱即用指标（HTTP Handler、Go Runtime）帮助我们很快获得了投资回报——仅 goroutine 指标就多次拯救了我们。我们之前唯一真正喜欢的监控组件——Grafana ——感觉与 Prometheus 是天作之合，让我们创建了一些非常有用的仪表盘。我们很欣赏 Prometheus 没有试图重复造轮子，而是与现有最佳解决方案完美融合。相比于前辈们，Prometheus 的另一个巨大进步是它专注于确保数学计算的正确性（百分位数等）。在其他系统中，我们从来不能完全确定所提供的操作是否有意义。特别是百分位数，它是一种非常自然且必要的推理微服务性能的方式，很高兴看到它们得到了一等公民的待遇。

集成的服务发现使得管理抓取目标变得超级容易。对于 Kubernetes，一切都是开箱即用的。对于一些尚未在 Kubernetes 上运行的其他系统，我们使用一种基于 Consul  的方法。要让一个应用程序被 Prometheus 监控，只需添加客户端、暴露 `/metrics` 并在容器/Pod 上设置一个简单的注解。这种低耦合减少了开发和运维之间的大量摩擦——许多服务从一开始就构建得很好，因为这既简单又有趣。

时间序列和巧妙函数的结合，赋予了告警超凡的能力。在服务器上运行的聚合，以及将时间序列、它们的组合甚至是在这些组合上的函数都作为一等公民对待，使得告警变得轻而易举——通常是在事后也能轻松处理。

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

虽然我们非常重视 Prometheus 不追求华而不实，而是专注于实际工作、交付价值，同时又相当容易部署和操作——但特别是 Alertmanager 还有很多地方有待改进。哪怕只是一些简单的改进，比如在前端简化交互式告警的构建和编辑，就能让处理告警变得更加简单。

我们非常期待存储层的持续改进，包括远程存储。我们也希望 Project Prism  和 Vulcan  中采取的一些方法能够被移植回 Prometheus 核心。目前我们最感兴趣的主题是 GCE 服务发现、更简单的扩展性，以及更长的数据保留期（即使代价是冷存储和更长的旧事件查询时间）。

我们也期待将 Prometheus 用于更多非技术部门。我们希望用 Prometheus 覆盖我们大部分的 KPI，让每个人都能创建漂亮的仪表盘和告警。我们目前甚至计划将这个强大的告警引擎用于一个新的内部业务项目——敬请期待！