日均TB級資料處理：微博廣告智慧監控系統搭建之路
彭冬， 微博廣告基礎架構團隊負責人。 朱偉， 微博廣告SRE團隊技術負責人。 劉俊， 微博平臺部監控技術負責人。 王莉， 在微博廣告團隊中致力於用資料分析和機器學習模型優化廣告業務策略，洞悉商業價值。 陸松林， 微博廣告資料倉庫負責人。 車亞強， 微博廣告大資料開發工程師。
計算廣告系統是集智慧流量分發、投放、結算、CTR預估、客戶關係管理等為一體的大型網際網路業務系統，隨著微博業務的快速增長，廣告系統的複雜度越來越高，成千上萬的模組需要不停地進行計算和通訊，如何保證這麼複雜的系統正常、健康執行是一個巨大的挑戰。
微博廣告智慧監控系統依託兩大平臺：D+（Data Plus）和Hubble平臺。
D+屬於商業基礎大資料平臺，它負責資料採集、儲存、計算和分析，並作為底層技術對上層應用提供API資料介面。Hubble（哈勃，其含義是資料如浩瀚宇宙之大，Hubble如太空望遠鏡，能窺見璀璨的星辰，發現數據的真正價值）平臺定位為微博廣告智慧全景監控、資料透視和商業洞察，與實驗平臺、效果分析平臺、DMP、廣告投放後臺等共同構成了D+的上層應用生態。
微博廣告Hubble平臺每日處理TB級別的監控資料和萬級別的報警規則，Hubble平臺利用機器學習技術進行趨勢預測和報警閾值的智慧調整，保證商業產品上千臺伺服器和數百個系統及服務的正常執行。
一、背景介紹
1、監控指標體系
通常，可以用系統處理監控指標的量級（目前已達百萬級別）來衡量監控平臺的處理能力。這個衡量指標在一定程度上可以反映監控平臺的複雜度和能力，但是在實際業務中並不一定需要這麼龐大的監控指標體系，很大一部分監控指標是毫無價值或多餘的。這些指標要麼根本無法真實反映系統或者業務的狀態，要麼可以直接被其他指標所取代，要麼需要結合更多的資訊來分析。
總體而言，監控指標有以下幾個分類：
機器（系統）指標
機器（系統）指標，主要指從機器資源角度設定的與機器本身比較相關的指標。概括起來，機器（系統）指標包括機器CPU、Memory、Disk IO／Space、Net IO等。
監控系統指標的目的是：發現機器故障、限流與擴容。
應 用指標
應用指標分為基礎應用指標和非基礎應用指標：
-
基礎應用指標是指由通用型的應用程式產生的指標，比如Nginx/Apache伺服器的請求狀態以及Access日誌和埠、SQL/">MySQL資料庫埠、Hadoop叢集執行狀態等。
-
非基礎應用指標是指非通用型應用程式（業務程式）所產生的指標，比如某個服務的埠號、程序個數等。另外，對於從業務程式產生的日誌中抽取出來的指標，也可以歸類於非基礎應用指標。
業務指標
業務指標是指關注具體業務、產品的指標，如日收入走勢、訂單數、廣告計劃數等業務層面的指標。
2、功能設計原則
在設計系統架構之前，應該先從業務和系統等角度深度挖掘架構要解決的核心問題。對於監控平臺而言，可以從平臺化、業務和系統架構及設計三個視角考慮來解析核心問題。
從平臺化視角考慮，監控報警平臺要解決的問題如下：
-
是否能指導RD快速定位問題；
-
是否為業務發展的預估提供了參考。
從業務視角考慮，監控報警平臺所要解決的核心問題主要有以下幾個方面：
-
監控指標：精準性和覆蓋率；
-
報警：實效性和準確性；
-
故障診斷；
-
自動處理。
從系統架構及設計視角考慮，監控報警平臺要能解決如下幾個方面：
二、整體架構
基於上述監控指標體系和功能需求，Hubble平臺的整體架構如圖1所示：
圖1：Hubble平臺的整體架構示意圖
Hubble整體架構包含三個層次：
資料採集層(Data Collection Layer)
資料採集層負責對系統日誌、系統指標、業務日誌、業務指標等資料進行實時採集。
對於日誌資料，支援Flume、Scribe等日誌收集工具，也支援Filebeat、Metricbeat等檔案及指標收集工具。
對於系統及業務指標，可以通過自主開發的w-agent客戶端進行資料收集。w-agent是Hubble的輕量級、低資源消耗的資料採集工具，它作為微博廣告標準基礎工具集的一部分，在伺服器初始化時進行安裝配置，通過ZooKeeper進行配置管理，支援遠端更新資料採集配置和配置變更實時生效。同時，資料採集層支援通過API的方式直接提交資料，方便資料個性化定製以適應不同的業務需求。
資料分析層(Data Analyzation Layer)
資料分析層負責將採集到的資料進行ETL、預處理、分析和聚合。為了提高可用性，採集到的資料將同時被寫入HDFS進行持久化，資料分析層可以根據需要，從HDFS中Reload資料並重新進行計算。另外，離線部分的監控預估模組會定時進行模型訓練，並將訓練後的模型儲存在HDFS中。Alert trigger模組負責根據報警規則進行報警觸發監測。
視覺化層(Visualization Layer)
經過分析處理的資料被寫入視覺化層的儲存系統中（如Druid、Elasticsearch、MySQL及ClickHouse），視覺化層負責根據業務方需求，對監控圖表進行展示、配置和管理，以及對報警資訊及規則進行管理。另外，視覺化層提供了API，允許第三方通過API的方式獲取聚合分析後的資料，以及對報警進行管理。
三、核心功能分析
1、全景監控
基礎監控
基礎監控要求實時反映真實的指標波動情況，其中關鍵技術之一是對時序資料進行聚合，其聚合粒度根據業務的不同而有一定的差異，當然也會受指標及資料處理量等因素的制約。目前Twitter、Facebook等國外公司一般做到30秒甚至分鐘級別聚合，大部分公司做到10秒級別聚合就已經可以滿足業務需求了。微博廣告監控系統根據業務需求，對部分指標的聚合粒度為1秒級別。
基礎監控底層使用D+平臺提供實時的資料服務。D+平臺是微博廣告商業資料基礎設施，負責資料收集、儲存、監測、聚合及管理，提供高可用的實時流和離線資料服務，在D+上可以對不同的資料來源及實時資料與離線資料進行關聯。
D+的整體架構簡圖如圖2所示：
圖2：D+的整體架構簡圖
基礎指標資料、日誌資料會從D+流出到ETL部分進行資料處理，然後輸入到Druid中提供上層Graph展示，同時輸出一部分資料（日誌）進入Elasticsearch，以便後續查詢。D+位於Hubble整體架構中的資料採集層和資料分析層，請參考圖1。
服務全景圖
假設對監控平臺的要求是隻允許用一到兩個檢視來清楚地展現服務監控狀態，對所有的需求和指標進行優先順序排序，則可以抽取出兩個關鍵維度，即機器維度和服務維度。
機器維度
在機器維度檢視下，核心是要清楚地確定所有機器的基本狀態，可以簡化為健康、亞健康和病態三種狀態：
-
健康狀態： 表示對機器資源（CPU、記憶體、網路I/O、頻寬、機器負載等）的使用一切正常，在未來一段時間（如7天）內可能也會正常，機器使用者完全不用擔心。
-
亞健康狀態： 表示對機器資源的使用存在一定的風險，如高峰期網路I/O太高，但仍然未達到影響機器正常執行的程度，機器使用者需要考慮機器I/O型別或者擴容，以便應對短期內可能產生的壓力。
-
病態： 是指對機器的某種資源的消耗已經達到上限，如磁碟已滿，需要機器使用者立即處理。
根據這樣的需求，設計出的檢視如圖3所示：
圖3：服務全景圖（機器維度）
當某臺機器出現異常時，能展示當前機器的異常級別、時間及具體的異常資訊。
服務維度
在服務維度檢視下，我們關心的核心問題是業務應用執行是否正常、整個鏈路是否通暢、是否有異常和告警、出現異常時影響了多少個節點等。並且，可以檢視在名稱空間下所有關聯服務上下游的整體健康狀態，針對異常節點展示異常原因和監控報表。
同時，結合自動化平臺，對服務之間的上下游關係（拓撲圖）進行展示，如圖4所示：
圖4：服務全景圖（服務維度）
2、趨勢預測
目前很多企業都在嘗試通過趨勢預測的方式，提前預測系統或者業務的未來發展狀況，未雨綢繆。業內普遍的做法是採用統計學的方法，如Holter-Winter、ARIMA、3Sigma等。 這類方法的特點是簡單，能結合部分歷史資料進行趨勢預測。
然而，它們也有很多不足之處，比如ARIMA演算法的一個技術難點就是時間序列的平穩化，平穩化的時間序列對於預測結果的好壞起著至關重要的作用。
微博廣告團隊率先嚐試通過機器學習的方法來預測系統指標的變化趨勢，取得了一定的效果，目前已經應用於廣告曝光量、互動量的趨勢預測。
基於機器學習的趨勢預測架構示意圖如圖5所示：
圖5：基於機器學習的趨勢預測架構示意圖
該架構主要分兩部分：離線模型訓練和線上計算。離線部分的資料來源是HDFS儲存的歷史指標資料，輸出為模型；線上部分根據模型計算後匯入Druid中進行儲存和部分聚合，通過Dashboard進行實時展示。
離線模型訓練模組的具體處理流程：
監控資料的獲取和儲存
首先將監控預警平臺的監控資料從HDFS中提取出來進行數值化。我們在向該模組提供的獲取資料介面中傳送帶有時間戳的GET請求，獲得了連續8天的監控資料作為訓練資料集。選取8天這個時間跨度，是充分考慮了監控資料自身可能蘊含的週期性與前後關聯性的。
生成模型訓練資料集
訓練集的視窗長度是指需要幾個時間點的值來預測下一個時間點的值。在這裡視窗長度為3，即用t-2，t-1，t次的時間間隔進行模型訓練，然後用t+1次的時間間隔對結果進行驗證。資料集格式為：X為訓練資料，Y為驗證資料。我們選取資料集中前66.7%的資料作為訓練集，後33.3%的資料作為測試樣本集。
LSTM模型結構與引數設定
圖6展示了LSTM（長短期記憶網路）的一個單元結構：
圖6：LSTM單元結構圖
LSTM單元是預測模型的一個重要組成部分，用於處理時間序列資料。xt表示輸入，ht-1表示上一時刻的狀態，ht表示當前時刻的狀態，W表示權值。
需要確定LSTM模組的啟用函式（在Keras中預設選擇tanh作為啟用函式）；門之間的啟用函式一般選擇Sigmoid函式，Sigmoid函式輸出0~1之間的數值，描述每個部分有多少量可以通過，其中0表示“不許任何量通過”，1表示“允許任意量通過”。
將接收LSTM輸出的全連線神經網路（Fully-Connected Neural Network）的啟用函式設為linear（線性）函式；將每一層網路節點的捨棄率（dropout的值）設為0.2；使用均方誤差（Mean Squared Error）作為誤差的計算方式；採用RMSprop演算法作為權重引數的迭代更新方案，該演算法對RNN網路通常有較好的收斂效果。
選定模型訓練的epoch（總的訓練輪數）為50和batch size（每次訓練的樣本數）為1，並在LSTM層的輸出後面加入一個普通的神經網路全連線層用於輸出結果的降維。
模型訓練
為了防止過度擬合，將上述獲取到的8天時間跨度的資料集按2:1的比例隨機拆分為訓練集和測試集。訓練模型後將資料的X列作為引數匯入模型便可得到預測值，與實際的Y值相比較便可知道該模型的優劣。將整個模型訓練完成後的引數儲存為h5py格式（Keras標準模型格式）的檔案，方便在以後的預測或呼叫中使用。
儲存模型結果
將訓練完成後的標準的h5py格式的Keras神經網路模型存入HDFS中，用於離線部分資料處理。
結果展示
實時線上部分從Kafka中獲取實時資料，並使用HDFS中訓練完成的模型進行計算，將計算結果的資料存入Druid中進行圖形化展示。
圖7展示了微博廣告某產品曝光量（PV）趨勢預測曲線效果圖：
圖7：趨勢預測曲線效果圖
（注：圖中展示了一週（7天）的資料趨勢，其中前5天為訓練資料走勢情況，後2天為預測資料走勢情況）
分析最終得到的效果圖，前面（5天）畫出了訓練資料的趨勢曲線，後面（2天）畫出了預測資料的趨勢曲線，可以從圖中看到最終的預測曲線與實際的曲線趨勢情況基本吻合，擬合效果非常出色，很好地將原始資料的波峰、波谷以及週期性預測出來了。
運維人員可以通過綠色預測曲線來預判監控曲線的整體走勢，並且可以瞭解到可能出現問題的時間點， 在 可能發生報警的時間點之前做好準備工作，未雨綢繆，做到心中有數。
時間序列預測是一類相對比較複雜的預測建模問題，和迴歸分析模型的預測不同，時間序列模型依賴事件發生的先後順序，同樣大小的值改變順序後輸入模型產生的結果是不同的。因此，我們選用LSTM模型對監控資料進行預測。
LSTM是RNN（迴圈神經網路）的變體，LSTM的特點就是在RNN結構基礎上添加了各層的閥門節點。這些閥門可以開啟或關閉，用於判斷模型網路的記憶態（之前網路的狀態）在該層輸出的結果是否達到閾值，從而加入當前該層的計算中。
閥門節點利用Sigmoid函式將網路的記憶態作為輸入進行計算，如果輸出結果達到閾值，則將該閥門輸出與當前層的計算結果相乘作為下一層的輸入；如果沒有達到閾值，則將該輸出結果遺忘掉。 每一層包括閥門節點的權重都會在每一次模型反向傳播訓練過程中更新。
LSTM模型的記憶功能就是由這些閥門節點實現的。當閥門開啟時，前面模型的訓練結果就會關聯到當前的模型計算，而當閥門關閉時之前的計算結果就不再影響當前的計算。因此，通過調節閥門的開關，我們就可以實現早期序列對最終結果的影響。
在Python中有不少包可以被直接呼叫來構建LSTM模型，比如：Kears、TensorFlow、Theano等。我們選用Keras作為模型定義與演算法實現的機器學習框架，將Keras整合到TensorFlow中，讓Keras變成TensorFlow的預設API。讓Keras執行在TensorFlow框架上，可以幫助我們快速搭建和實現一個神經網路模型。
相對於現有的預測演算法，如Holter-Winter、ARIMA、3Sigma，LSTM對監控資料的預測準確性較高。比如3Sigma演算法在實際預測中給出的值往往並不理想，上下文之間的關聯性並不強，運維人員如果直接在給出的預測值上進行分析或者預警，效果可能會與實際偏差較大。
而LSTM能很好地抓住時間序列上下文可能存在的聯絡，並利用這種聯絡做出預測。我們想利用該模型的前後關聯性和資料本身存在的關聯性，對監控資料做出合理的預測。
LSTM對未來資料的走勢給出了直觀的預測，趨勢預測的結果可以為運維人員提供良好的參考，對於可能發生報警的情況，運維人員可以較早地採取有針對性的措施，有效地減少報警的次數，減輕了運維人員的工作負擔。基本達到了不漏報和不誤報的平衡，同時根據大量的歷史監控資料訓練出的模型有很強的泛化和預測能力，不用實時地加入資料更新訓練，也不需要耗費人力、物力進行長期維護。後期的工作只需要將更新的模型替換到預測模組中即可。我們可以將節省下來的監控的人力成本，投入到智慧監控的研究當中。
圖8展示了微博廣告某產品曝光量預測值與實際值偏差佔比分佈情況：
圖8：微博廣告某產品曝光量預測值與實際值偏差佔比分佈情況（單位：PV）
可以看到，對於PV預測值與實際值小於1000的佔比約為73%，小於1500的佔比約為96%。按照1000次曝光（PV量）轉化為廣告計量單位為1CPM，1.5CPM內的誤差佔比為96%。
需要注意的是，目前基於機器學習的趨勢預測還不能很好地支援對精度要求非常高的指標，如按點選收費的廣告互動數指標。
3、動態閾值
系統報警往往結合監控來做，對於某個指標觸發所設定的閾值後向相關人員傳送訊息提醒。
目前大多數做法是固定閾值，這個閾值是根據經驗設定的，其優點是簡單、直接、操控性強；其缺點是經驗值不準，如果GAP設定得過小，則會增加報警次數，導致誤報率增加；如果GAP設定得過大，又會導致漏報。
另外，很多資料指標的波動呈週期性變化，通過經驗或者人工很難設定一個合適的GAP。為此，可以結合趨勢預測技術，在預測的基礎上增加動態閾值，比如報警條件為趨勢預測曲線上下10%，這個百分比可以根據業務進行調整。
4、服務治理
要想讓一個系統變得健壯，具有高可用性，除需要完善的監控分析、及時的報警策略等被動方式外，還需要主動發現系統中可能存在的隱患。
特別是在微博這樣的平臺中，無法預知什麼時候會有流量高峰，更無法預知這個高峰會有多高。比如一個熱門事件就可能導致流量瞬間飆升，如2017年鹿晗、關曉彤公佈戀情，微博廣告的流量在1分鐘內就飆升了近一倍，即使是動態擴容的速度也趕不上這樣瞬間突發的流量高峰。
所以，面對這樣的場景，如何把控系統，對系統的每個服務、每個節點的承載能力及瓶頸、缺陷都瞭然於胸，才能及時封堵缺口，快速響應故障。
環境選擇
流量壓測的方式有很多種，可以對單臺機器、單個服務進行流量壓測，也可以通過將流量集中轉發到線上一小部分服務來提高單臺伺服器的QPS，還可以搭建一個和線上環境一模一樣的系統。但是上述方法都不能模擬生產環境的真實情況。
單臺機器和單個服務的流量壓測對於測試單機效能和單個服務能夠承載的最大QPS是可以的，但是這樣的結果永遠都只是一個理論值，往往評估出來的結果過高。因為它忽略了上下游服務的依賴，如果一個服務被要求在10ms內響應請求，它自身需要消耗2ms的執行時間，但是下游響應它的時間卻超過了8ms，這樣，最終結果在上游看來都是超時的。也許所有服務壓測出來的結果都能滿足要求，但是服務與服務之間的網路質量又有可能成為瓶頸。
將流量集中轉發到線上一小部分服務來提高單臺伺服器的QPS，這樣的方法對整個系統一部分服務節點的流量評估可能是合理的，但是不能忽略了服務後端訪問的儲存類資源，很多時候我們並不能做到對儲存類資源也集中流量。
至於搭建一個和線上環境一模一樣的系統，依然沒法確保服務之間的網路質量都是一樣的，也沒法確定會不會有一些其他因素可能影響流量評估的結果。更何況對於很多公司來說，在同樣的機房中，具有相同的機器數量，擁有相同的軟硬體配置和環境，搭建一個測試環境並不是一件容易的事情。
所以，綜合來看，只有以線上環境為測試環境，將測試流量直接匯入線上環境中，才能真正模擬流量高峰下系統的可用性，無論是前端服務還是計算節點，抑或是後端儲存類資源，都可以真實展現它們在流量高峰下的效能和問題。
雖然這樣做是一件很冒險的事，但是如果我們做好足夠的準備工作，小心翼翼地進行，那麼就可以將風險降到最低。
流量壓測/容量評估
GoReplay是一款用於捕獲和重放實時HTTP流量的開源工具，可以不間斷地用線上實時流量來測試系統性能。
採用Go開發的GoReplay部署簡單，只需下載一個可執行檔案就可以在生產環境中的伺服器上捕獲指定埠的流量並轉發到測試環境中，或者新增一個測試流量的標識，再重新發送到生產環境中，如圖9所示：
圖9：GoReplay流程示意圖
通過GoReplay轉發HTTP請求示例如下：
./goreplay # 從80埠捕獲HTTP請求 --input-raw :80 # 設定自動退出時間 --exit-after 60s # 將請求轉發到192.168.1.1的80埠 --output-http "192.168.1.1:80" # 將10%請求轉發到192.168.1.2的8080埠 --output-http "192.168.1.2:8080|10%" # 自定義測試流量標識 --http-set-header 'User-Agent: Gor' # 指定超時時間 --output-http-timeout 100ms # 輸出請求狀態 --stats --output-http-stats
效能評估
可以通過GoReplay將線上流量複製一份或者多份，然後匯入線上環境中，線上環境通過HTTP Header來區分真實流量和測試流量。接下來要做的就是在線上系統流量翻倍的情況下，通過全鏈路Trace系統來觀察各個服務節點的效能瓶頸。
全鏈路Trace系統是通過在每個請求中增加全域性唯一的Trace ID，在服務與服務之間增加Span ID、Timestamp等資訊，來全域性跟蹤一條流量處理鏈路的。通過全鏈路Trace系統還可以統計QPS在各個服務節點的變化，以及每個節點處理請求的耗時佔比。
通過全鏈路Trace系統，可以很直觀地發現在流量高峰下，各個服務節點處理請求的QPS、耗時分佈、狀態碼分佈等指標資訊，為下一步的系統優化提供可靠的資料依據。
四、小結
監控系統首先要解決的問題是指標覆蓋率，大而全，然後在此基礎上進行深耕，提高準確性，最後是精簡和抽象，發現數據後面最本質的東西。微博廣告基礎架構團隊在監控方面有一定的積累，並率先在監控中利用機器學習技術進行了一些嘗試，未來將在智慧預測和服務自動化處理（降級、恢復等）方面進行更深入的嘗試。