继续我们对 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 处理程序。我们还编写并部署了几个导出器（exporters），包括 node_exporter 以及几个用于云服务提供商 API 的导出器。根据我们的经验，监控和告警是一个永无止境的项目，但大部分工作在几周内作为副项目完成了。
部署 Prometheus 以来，每当我们遗漏了什么，或者从头设计新服务时，我们都会倾向于查看指标。
完全理解 PromQL 和标签概念的精妙之处花了一些时间，但这些努力确实得到了回报。
切换到 Prometheus 以来，您看到了哪些改进？
Prometheus 让我们豁然开朗，它使白盒监控和基于标签的金丝雀部署的好处变得触手可及，异常简单。许多 Golang 方面的开箱即用指标（HTTP Handler、Go Runtime）帮助我们非常迅速地获得了投资回报——仅 goroutine 指标就多次力挽狂澜。我们之前唯一真正喜欢的监控组件——Grafana——与 Prometheus 感觉天作之合，并让我们创建了一些非常有用的仪表板。我们赞赏 Prometheus 没有试图重塑轮子，而是完美地契合了现有的最佳解决方案。相对于前辈们的另一个巨大改进是 Prometheus 专注于准确地进行数学计算（百分位数等）。在其他系统中，我们从来都不确定提供的操作是否合理。特别是百分位数是推理微服务性能的一种如此自然和必要的方式，看到它们得到一流的处理感觉非常棒。
集成的服务发现使得管理抓取目标（scrape targets）变得非常容易。对于 Kubernetes，一切都开箱即用。对于一些尚未运行在 Kubernetes 上的系统，我们使用基于 Consul 的方法。要让一个应用被 Prometheus 监控，只需添加客户端库，暴露 /metrics 接口，并在 Container/Pod 上设置一个简单的注解。这种低耦合消除了开发和运维之间的很多摩擦——许多服务从一开始就构建得很好，因为这既简单又有趣。
时间序列和巧妙函数的结合带来了强大的告警能力。在服务器上运行的聚合操作，以及将时间序列、它们的组合甚至这些组合上的函数视为一等公民，使得告警变得轻而易举——通常在事后进行。
您认为 JustWatch 和 Prometheus 的未来会怎样？
虽然我们非常珍视 Prometheus 不追求华丽，而是专注于实际工作和交付价值，同时部署和操作相对容易——但 Alertmanager 仍有很多不足之处。只需一些简单的改进，比如前端简化交互式告警构建和编辑，就能让处理告警变得更加简单。
我们非常期待存储层的持续改进，包括远程存储。我们也希望 Project Prism 和 Vulcan 中的一些方法能被回迁到 Prometheus 核心。目前对我们来说最有趣的话题是 GCE 服务发现、更轻松的扩展性以及更长的保留期（即使以更冷的存储和更长的旧事件查询时间为代价）。
我们也期待将 Prometheus 用于更多非技术部门。我们希望用 Prometheus 覆盖我们大部分的关键绩效指标（KPIs），让每个人都能创建漂亮的仪表板和告警。我们目前甚至计划将强大的告警引擎“滥用”于一个新的内部业务项目——敬请期待！