嘉賓介紹：陸琴，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的，這個可能會有比較大的改動。
同時也就像我剛纔所介紹的那樣，在自動化、智能化方面，我們也有一些想法，希望能夠更好地來利用監控平臺，能夠減少人工的干預，幫我們自動的發現、修復一些問題。