JustWatch 访谈

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

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

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

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

自 2014 年成立以来，我们在没有花费一分钱营销费用的情况下，从零发展成为全球排名前 20000 的大型网站之一，在不到两年的时间里成为全球最大的流媒体搜索引擎。目前，我们仅有 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 处理器、Go 运行时）的开箱即用指标帮助我们很快获得了投资回报——仅 goroutine 指标就多次拯救了我们。之前我们唯一真正喜欢的监控组件——Grafana——感觉与 Prometheus 天生绝配，让我们创建了一些非常有用的仪表盘。我们很欣赏 Prometheus 没有试图重复造轮子，而是与市面上最好的解决方案完美结合。相比于前辈们，Prometheus 的另一个巨大改进是它专注于确保数学计算的正确性（百分位数等）。在其他系统中，我们从来不确定它们提供的操作是否有意义。特别是百分位数，它是一种非常自然且必要的衡量微服务性能的方式，Prometheus 对其提供了一等公民待遇，这感觉太棒了。

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

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

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

虽然我们非常欣赏 Prometheus 不追求华而不实，而是专注于实际工作、交付价值，并且部署和运维相对简单——但尤其是 Alertmanager 还有很多需要改进的地方。仅仅是一些简单的改进，比如在前端简化交互式告警的构建和编辑，就能让告警工作变得更加简单。

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

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