继续我们对 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 处理程序、Go 运行时）帮助我们很快获得了投资回报 - 仅 goroutine 指标就多次力挽狂澜。我们之前真正喜欢的唯一监控组件 - Grafana - 感觉与 Prometheus 非常契合，并允许我们创建一些非常有用的仪表板。我们很欣赏 Prometheus 没有试图重新发明轮子，而是完美地适应了现有的最佳解决方案。相对于之前的系统，Prometheus 的另一个巨大改进是专注于真正把数学运算做好（百分位数等）。在其他系统中，我们从不确定提供的操作是否有意义。尤其是百分位数，它是推理微服务性能的一种自然且必要的方式，它们获得了一流的待遇，这感觉很棒。
集成的服务发现功能使管理抓取目标变得非常容易。对于 Kubernetes，一切都开箱即用。对于一些尚未在 Kubernetes 上运行的其他系统，我们使用基于 Consul 的方法。要使应用程序受到 Prometheus 监控，只需添加客户端，公开 /metrics 并在 Container/Pod 上设置一个简单的注解即可。这种低耦合性消除了开发和运维之间的许多摩擦 - 许多服务从一开始就被很好地编排构建，因为它既简单又有趣。
时间序列和巧妙函数的结合造就了强大的警报超能力。在服务器上运行的聚合，以及将时间序列、它们的组合，甚至这些组合上的函数都视为一等公民，使得警报变得轻而易举 - 通常是在事后。
您认为 JustWatch 和 Prometheus 的未来会怎样？
尽管我们非常赞赏 Prometheus 不专注于华而不实，而是专注于实际工作和交付价值，同时易于部署和操作 - 但特别是 Alertmanager 还有很多不足之处。只需进行一些简单的改进，例如在前端简化交互式警报构建和编辑，就可以大大简化警报的使用。
我们非常期待存储层的持续改进，包括远程存储。我们也希望 Project Prism 和 Vulcan 中采用的一些方法能够反向移植到核心 Prometheus 中。目前我们最感兴趣的主题是 GCE 服务发现、更轻松的扩展以及更长的保留期（即使以更冷的存储和更长的旧事件查询时间为代价）。
我们还期待将 Prometheus 用于更多非技术部门。我们希望使用 Prometheus 覆盖我们的大多数 KPI，以便每个人都可以创建漂亮的仪表板以及警报。我们目前甚至计划将强大的警报引擎用于一个新的内部业务项目 - 敬请期待！