实时监控系统如何帮助FreeWheel支持超级赛事直播广告？

嘉宾介绍：陆琴，2010年加入FreeWheel，目前是FreeWheel监控平台高级经理，同时负责Adserving部门质量保证工作。陆琴在软件测试理论、测试平台搭建、如何设计并保证高可用系统等方面拥有丰富的经验，曾任Adserving部门首席测试工程师。2017年起，负责搭建FreeWheel监控平台，倡导技术变革和理念更新，为FreeWheel如何使用实时监控平台保证超级赛事直播质量做出突出贡献，先后带领团队组织并实施了超级碗、奥运会、世界杯等在线支持。在加入FreeWheel之前曾于暴风影音工作。

InfoQ：介绍一下您自己以及FreeWheel的主要业务？

陆琴：您好，我叫陆琴，是FreeWheel监控平台的高级经理，之前是在FreeWheel广告投放部门任首席测试工程师。从2017年开始，我们重新开始搭建新的监控平台，基于新搭建的监控平台，带领团队支持了从今年2月份开始的超级碗、冬奥会，还有今年的世界杯等直播赛事，最近也正在做NFL美国橄榄球联赛的直播。

我们的公司叫FreeWheel，它的中文名叫飞维美地，主要业务就是通过在不同的视频终端上，通过广告来变现优质视频。我们提供的是一体化的视频广告解决方案，包括视频广告的管理、投放、预测还有报表等等的增值服务，是美国本土领先的视频广告管理和投放平台。

我们服务了全美大概90%的主流电视媒体和运营商。 传统运营商，比如说Comcast、COX，有点类似于中国的歌华有线，还有一些传统的电视台，比如说ESPN、FOX，有点像国内的湖南卫视、浙江卫士。同时我们还有一些纯数字化的平台，比如索尼、Crackle这样的公司，有点像我们国内的爱奇艺、优酷这样的视频平台。
所以我们公司的覆盖面还是非常广的。

InfoQ：直播视频广告有什么特点？

陆琴：我想大家平常都看过直播视频，NBA是一个非常典型的例子，还有美国比较流行的NFL橄榄球比赛，都是特别典型的例子，可能跟足球比赛不一样，因为足球比赛的直播，广告点基本上比较固定，就是中场休息，但是对于像NBA、NFL橄榄球比赛，你根本就不可能知道教练什么时候叫暂停，所以也就不知道具体的广告时间。对于我们系统来说，主要有三个特点：高并发、实时响应和高可用。 高并发：直播赛事进广告的时候，几乎是所有用户都同时发起广告请求， 也就是说，所有的广告请求几乎同时要发给广告投放服务器，导致我们系统面临突发的高并发的压力。

实时响应，就像刚才说的NBA和NFL橄榄球比赛的广告时机不可预测，从知道可以插入广告到用户看到广告播放，只有短短数秒时间，需要我们的广告服务器能实时响应。

第三个是高可用性，对于直播来说，广告机会一旦错过，不可恢复。跟购物网站对比，极端情况下的可用性，只是影响用户体验，而直播广告系统，直接影响客户的收入。而我们公司支持的直播赛事又都是超级直播赛事，所以对于我们系统的要求会更高一些。

所以基于这样三个特点，对我们的监控平台也会带来比较大的压力，要求我们的广告投放平台非常稳定，也就要求我们的监控平台也能够做到实时地发现以及定位线上的问题。

InfoQ：FreeWheel的实时监控平台在设计的时候有哪些考虑？采用了哪些组件？

陆琴：首先对于我们的监控平台来说，我们第一是要符合广告投放系统的一些特点，像刚才说直播广告有这样那样的特点，其实就对我们的监控平台提出了一些要求，所以我们也是基于直播广告的特点来设计我们的监控平台。

第一，需要有统一的监控平台，需要我们能基于应用、系统、业务做立体全方位的监控。

第二，数据可插拔，支持接入各种各样的数据，支持各种模块、各种组件、以及各种模式的数据。

第三，实时响应。我们的广告请求都是非常快的进来，所以我们要能够抓住这样的广告请求的时机，我们的监控平台也要能够实时响应。现在我们线上的广告平台数据采集频率是10秒钟的时间。

还有像任何一个监控平台一样，它也要具备数据
的可视化，故障分析和定位的功能，通过可视化仪表盘能够直接获取系统的运行状态、资源使用情况、以及服务运行状态等直观的信息。 监控系统能够通过各种监控指标，历史趋势分析、帮助我们找到及解决根源问题。

最后一点，自动化和智能化。当线上报警触发后，可以通过自动化运维的方式来止损，同时我们会引入人工智能的方式，自动识别abnormal pattern，进而判断异常的发生。

我们的监控平台采用了哪些组件，其实我们的监控平台跟任何其他的监控平台一样，我们都有四个模块组成，第一是数据采集，第二是数据存储与查询引擎，第三是数据的可视化，第四是报警，能把问题通知到相关的人。

首先我们来说一下数据采集，我们主要是通过Prometheus的方式来做数据采集的，因为Prometheus定义了标准的监控指标类型，也有很多开源的exporter能够帮助我们去做监控数据的采集。

我们自研的应用会基于Prometheus的client library 来定义应用自己的监控指标， 而对于通用的服务，如mysql, kafka等，会使用相应的exporter来帮助我们做监控. 数据都是通过Prometheus来采集。同时我们也自研了一个Prometheus监控指标的转换适配器，我们叫它Gather。对于一些历史遗留性的服务，比如cronjob、或者script 脚本类的服务，它不太适合通过Prometheus的接口来暴露监控指标, 于是我们就开发了Gather，Gather是运行部署在本地的，它其实就相当于是本地的Prometheus的native collector agent，它能够帮我们把本机的所有监控指标都收集起来，并且转换成Prometheus的格式，供Prometheus来采集。这是我们的数据采集部分。

数据存储主要是用InfluxDB来做Prometheus的远程存储，因为InfluxDB的cluster版本是要收钱的，所以我们也通过自研的方式，开发了数据库的中间件DB-Proxy。通过这个DB-Proxy能够帮我们实现数据库读写的高可用、负载均衡、数据库的扩容等等。

由于我们的数据采集是Prometheus，而数据的存储是InfluxDB，所以就存在一个数据转换的问题。我们也把Prometheus的Influxdb remote read adapter实现到我们的DB-Proxy里面去了。同时我们也对于Prometheus到InfluxDB数据转换的查询这块也做了一些相应的优化，这是我们的数据存储。

我们还采取了开源Trickster 查询缓存，来帮助我们减少数据库的查询压力。Trickster是Comcast开源的，专门针对Prometheus数据的查询缓存工具。 这是数据存储和查询我们主要用到的一些组建。

我们的UI dashboard基本上都是用Grafana来做展现的。

最后来说一下Alert报警模块。我们的Alert其实是使用了InfluxDB的原生Alert模块叫Kapacitor，但是如果只使用它来做报警的话会导致Alert泛滥的问题，因为它没有做报警收敛的功能。所以在这个基础上我们又自研了alert manager来帮助我们基于时间维度和业务维度的报警聚合，同时报警的历史数据存入数据库，便于我们对alert进行分析和处理。同时由于我们需要对Alert Rule进行增删改查的操作，所以我们也自研了UI和API。刚才也说到alert被触发之后，我们要支持后续的自动化运维，所以我们也开发了Alert post action来支持警报自动化运维处理及故障定位与分析。这些就是我们的监控平台主要用到的模块组件。

InfoQ：FreeWheel的实时监控平台，它是怎么样帮助工程师提前发现一些线上的问题的？

陆琴：这个方面，真的还有挺多可以说的，因为在我们的实时监控平台发展到当前阶段之前，经常会遇到一些问题，比如在线上报警报出来的时候，我们已经来不及处理止损了。现在我们是基于系统、业务、应用三维一体的来去做线上的监控。我认为很重要的一点是在我们去重新搭建新的监控平台的过程中，我们跟各个应用方一起梳理了应用本身，它到底需要做哪些监控、哪些地方需要去做监控。所以在平台和应用方共同的努力下，我们对于系统和应用都加了很多监控指标。 同时为了防止问题在最后一刻才被爆出来，以致我们没有办法止损的情况，我们对报警定义了不同的级别，例如info、warning和critical。对info级别设的报警条件相对松一些，到critical，那真的是很critical的问题。我们现在线上的情况是，当有一些苗头的时候，潜在的问题就通过info或者warning的方式发现、报告出来了。有一个很常见的例子，出现过很多次的，是我们的广告投放系统的性能下降的问题。

我们线上的广告投放系统的性能，它依赖于广告投放服务器它所服务的线上流量。虽然我们自己会针对于线上的流量来做线下的流量回放，但仍然会有一些意想不到的集成上线，而工程师们没法提前知道。所以我们把系统性能指标的报警设得相对严格。有一点点下降的苗头，我们就提前都知道了。我们对性能指标做了非常详细的细分，到底有哪些方面有可能影响广告投放系统的返回时间，都有相应的监控指标。现在基本上当发现广告投放系统性能有下降的趋势时，我们都能够找出来到底是什么原因导致了性能下降。同时我们也会把原始的流量都记录下来，帮助我们来发现和还原问题。

InfoQ：FreeWheel实时监控平台确实是非常有特色的一个平台，但是不可能所有平台都是尽善尽美的，在您看来，FreeWheel实时监控平台还有哪些可以改进的地方？

陆琴：肯定有需要改进的地方，因为系统的发展是由小到大的，监控平台支持的监控数据也是由少到多，监控系统也是逐渐变得复杂的。所以大量的监控数据的接入对我们的监控平台本身也造成了一定的压力。 刚刚我也介绍了，我们采用InfluxDB作为我们的远程存储，它本身存在单点的问题，虽然我们用DB-Proxy作为中间件对它做了一些可扩展性等等的优化，但随着更大量数据量的接入，我们的远程数据存储也存在着性能瓶颈。所以我们现在也在考虑，是不是要切到OpenTSDB或者AWS Timestream这样的数据远程存储。

如果我们的数据存储切到另外的方式的话，就意味着我们的Alert模块也得做相应的改动。因为刚才我也介绍了，我们的Alert是基于的InfluxDB原生的Kapacitor的，这个可能会有比较大的改动。
同时也就像我刚才所介绍的那样，在自动化、智能化方面，我们也有一些想法，希望能够更好地来利用监控平台，能够减少人工的干预，帮我们自动的发现、修复一些问题。