JustWatch 访谈
2016年10月12日作者 Brian Brazil
作为我们 Prometheus 用户系列访谈的一部分，JustWatch 向我们分享了他们是如何建立监控系统的。
您能介绍一下自己以及 JustWatch 的业务吗？
对于消费者而言，JustWatch 是一个流媒体搜索引擎，帮助用户查找在哪些平台可以合法地在线观看或在影院观看电影和电视剧。您可以在 17 个国家/地区搜索包括 Netflix、HBO、Amazon Video、iTunes、Google Play 等在内的所有主流流媒体提供商的内容。
对于电影制片厂或视频点播 (VOD) 提供商等客户，我们是一家国际电影营销公司，通过消费类应用收集全球粉丝在购买行为和电影偏好方面的匿名数据。我们帮助制片厂将内容投放给目标受众，并显著提高数字视频广告的效率，减少无效覆盖。
自 2014 年推出以来，我们没有在营销上花费一分钱，就从零发展成为全球最大的 2 万个网站之一，在不到两年的时间内成为了全球最大的流媒体搜索引擎。目前，我们仅拥有 10 人的工程团队，构建并运行着一套完全容器化的架构，包含约 50 个微服务和宏服务，主要运行在 Kubernetes 上。
在使用 Prometheus 之前，您的监控体验是怎样的？
在之前的公司，我们许多人都使用过市面上大多数开源监控产品。我们在 Nagios 、Icinga 、Zabbix 、Monit 、Munin 、Graphite 以及其他一些系统方面积累了相当多的经验。在一家公司，我曾协助使用 Puppet 构建过分布式的 Nagios 设置。这种设置很好，因为新服务会自动显示在系统中，但移除实例的过程依然非常痛苦。一旦您的系统出现差异，基于主机和服务的监控套件就不再那么适用了。Prometheus 采用的基于标签（label）的方法一直是我梦寐以求的，在此之前我从未找到过类似产品。
你们为什么决定研究 Prometheus？
在 JustWatch，Prometheus 的公开宣布恰逢其时。公司成立的前几个月，我们主要进行黑盒监控——使用 CloudWatch 来处理一些最重要的内部指标，并结合像 Pingdom 这样的外部服务来检测全站性的宕机。此外，传统的基于主机的方案也无法令我们满意。在容器和微服务的世界中，像 Icinga、Thruk 或 Zabbix 这样的工具感觉已经过时，无法胜任工作。当我们开始调研白盒监控时，幸运的是我们的一些同事参加了 Golang Meetup，Julius 和 Björn 在会上宣布了 Prometheus。我们迅速搭建了一个 Prometheus 服务器，并开始对我们的 Go 服务进行指标埋点（我们的后端几乎全部使用 Go）。过程非常简单，这令人惊叹——它的设计初衷就是云原生和面向服务的，使用起来完全没有阻碍。
你们是如何过渡的？
迁移过程并不困难，因为从时间点上看，我们很幸运地直接从“无相关监控”过渡到了 Prometheus。
过渡到 Prometheus 主要涉及将 Go 客户端集成到我们的应用中并封装 HTTP 处理程序。我们还编写并部署了几个导出器（exporters），包括 node_exporter 以及用于云提供商 API 的多个导出器。以我们的经验来看，监控和报警是一个永无止境的项目，但大部分工作在几周内通过副业形式就完成了。
自部署 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，让每个人都能创建美观的仪表盘和报警。我们目前甚至计划将这个出色的报警引擎用于一个新的内部业务项目——敬请期待！