微博廣告Hubble系統：秒級大規模分散式智能監控平台架構實踐

業務背景

Hubble（哈勃，其含義是數據如浩瀚宇宙之大，Hubble 如太空望遠鏡，能窺見璀璨的星辰，發現數據的真正價值）平台定位為微博廣告智能全景監控、數據透視和商業洞察。

計算廣告系統是集智能流量分發、投放、結算、CTR 預估、客戶關係管理等為一體的大型互聯網業務系統。隨著微博業務的快速增長，廣告系統複雜度越來越高，成千上萬的模塊需要不停地進行計算和通信，如何保證這麼複雜的系統正常健康運行是一個巨大的挑戰。

微博廣告 Hubble 平台每日處理 TB 級別的監控數據和萬級別的報警規則，Hubble 平台利用機器學習技術進行趨勢預測和報警閾值的智能調整，保證商業產品上千台伺服器和數百個系統及服務的正常運行。

下面我將詳細介紹一下微博商業廣告 Hubble 系統的設計原理及在智能全景監控實踐中的一些思考。

核心問題

設計系統架構之前，應該首先從業務和系統等角度深度挖掘架構要解決的核心問題，對於監控平台而言，可以從平台化視角、業務視角及系統架構視角三個層面解析核心問題。

從平台化視角考慮，監控報警平台要解決的問題是

• 是否能指導 RD 快速定位問題？

• 是否為業務發展的預估提供參考？

從業務視角考慮，監控和報警平台所要解決的核心問題主要有以下幾個方面

• 監控指標：精準性和覆蓋率（Accuracy and Coverage rate）

• 報警：實效性和準確性（real-time performance and Accuracy）

• 故障診斷（fault diagnosis）

• 自動處理（Automatic processing）

從系統架構及設計視角考慮，監控報警平台要能解決：

• 大數據分析處理能力，包括數據採集、ETL和數據抽象分析

• 數據分析處理實時性

• 大規模監控指標等時序數據存儲、報警規則存儲及報警觸發

• 高可用性

• 數據聚合能力

簡單的講，Hubble 全景監控的核心功能包括提供基礎監控、報警、預警服務，如圖1所示。

圖1 Hubble全景監控服務核心功能

整體架構

Hubble 平台的整體架構如圖2所示。

圖2 Hubble平台整體架構圖

如圖2，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），可視化層負責根據業務方需求，進行監控圖表的展示、配置和管理，以及報警信息及規則的管理。另外，可視化層提供 APIs，允許第三方通過 API 的方式獲取聚合分析後的數據以及對報警的管理。

三層各個模塊相互協作，完成從數據搜集到可視化整個流程。

核心功能

監控指標

經常聽到同學說系統處理百萬級別的監控指標，以此來形容監控平台的處理能力，當然，這個數據在一定程度上可以反映監控平台的複雜度和能力，但是我們業務真的需要這麼龐大的監控指標么？實際上，很大一部分的監控指標是毫無價值或多餘的，這些指標要麼根本無法真實反應系統或者業務的狀態，要麼可以直接被其他指標取代，要麼是需要結合更多的信息來分析。

抽象出來，監控指標應該有以下幾個分類。

機器（系統）指標

這部分指標，從機器資源角度，尤其是從硬體瓶頸相關的早期跡象並捕獲硬體故障信號進行監控。抽象概括起來包括機器 CPU、Memory、Disk IO / Space、Net IO。

系統指標監測的目的是：

1. 發現機器故障

2. 限流與擴容

應用指標

應用指標分為基礎應用指標和非基礎應用指標。基礎應用指標是指能被標準化和常見應用的監控，比如 Nginx / Apache 伺服器的請求狀態和 access 日誌及埠、MySQL 資料庫埠、Hadoop 集群運行狀態等。非基礎應用指標，指針對基礎應用指標以外的應用指標，比如某個服務的埠號指標、進程個數等。另外，對於應用的日誌抽取出來的指標，也可以歸類於非基礎應用指標。

業務指標

業務指標關注具體業務、產品的指標，如日收入走勢、訂單數、廣告計劃數等業務層面的。

智能化全景監控實踐

基礎監控

基礎監控要求實時反應真實的指標波動情況，其中關鍵技術之一是對時序數據進行聚合，其聚合的粒度根據業務不同而有一定差異，當然也會因指標及數據處理量等因素制約。目前 Twitter、Facebook 等國外公司一般做的 30 秒甚至分鐘級別聚合，大部分公司做到 10 秒級聚合已經滿足業務需求。微博廣告監控根據業務需求，對部分指標聚合粒度為 1 秒級。

基礎監控底層使用 D+（Data Plus）平台提供實時的數據服務，其中D+平台是微博廣告商業數據基礎設施，負責數據搜集、存儲、監測、聚合及管理，提供高可用的實時流和離線數據服務，在D+上可以對不同數據源及實時數據與離線數據的關聯，關於D+技術架構細節，後續文章會進一步分享。

D+的整體架構如圖3所示。

圖3 D+系統架構圖

基礎指標數據、日誌數據會從 D+ 流出到 ETL 部分進行數據處理，然後輸入到 Druid 提供上層 Graph 展示，同時輸出一部分數據（日誌）進入 ElasticSearch，以便後續查詢，D+ 位於 Hubble 整體架構的 data collection layer 和 data analyzation layer，具體可結合參考圖2。

趨勢預測

目前很多企業都在嘗試通過趨勢預測的方式，提前預測系統或者業務的未來發展，以期望未雨綢繆，業內普遍的做法是通過統計學的方法，如 Holt Winter，ARIMA，3Sigma 等。

此類方法的特點是簡單，能結合部分歷史數據進行趨勢預測，然而也有很多不足，如 ARIMA 演算法的一個技術難點就是時間序列的平穩化，平穩化的時間序列對於預測結果的好壞起著至關重要的作用。另一個問題是滑動平均操作帶來的結果如波動鋸齒明顯，容易造成誤報干擾的化，則加大監控監測周期。

微博廣告團隊率先嘗試通過機器學習的方法來預測系統指標的變化趨勢，取得了一定的效果，目前已經應用於廣告曝光量、互動量的趨勢預測。

趨勢預測的架構圖4如下：

圖4 基於機器學習的趨勢預測架構圖

主要分兩部分：離線模型訓練和在線計算。離線部分的數據來源是 HDFS 存儲的歷史指標數據，輸出為模型；在線部分根據模型進行計算後導入到 Druid 進行存儲和部分聚合，通過 dashboard 可以實時展示。

由於 LSTM（長短時記憶網路，RNN 變體）能很好抓住時間序列上下文可能存在的聯繫的特性，因此模型訓練方面，我們選擇了 LSTM 模型，Python 中有不少包可以直接調用來構建 LSTM 模型，比如 Keras，Tensorflow，Theano 等，我們選用 Keras 作為本文模型定義與演算法實現的機器學習框架，選擇 backend 為 TensorFlow，同時使用均方誤差（mean squared error）作為誤差的計算方式，並採用 RMSprop 演算法作為權重參數的迭代更新方案。

圖5展示了微博廣告某產品曝光量（pv）趨勢預測效果圖。

圖5 趨勢預測曲線效果圖

註：紅色為訓練數據；藍色為實際值；綠色為測試輸出

圖6展示了微博某廣告產品曝光量預測值與實際值偏差的佔比分布。

圖6 趨勢預測效果圖

可以看到，對於 pv 預測值與實際值小於 1000 的大概佔比為 73%，小於 1500pv 的佔比約為 96%，按照 1000 次曝光（pv量）轉化為廣告計量單位為 1CPM，1.5CPM 內的誤差佔比 96%。

然而，基於機器學習的趨勢預測目前還不能很好支持對精度要求非常高的指標，如按點擊收費的廣告互動數指標。

動態閾值

系統報警往往結合監控來做，是指對於某個指標觸發某一個設定閾值後向相關人員發送消息提醒。目前大部分的做法是固定閾值，這個閾值是根據經驗設定，其優點是簡單直接、操控性強，其缺點是經驗值不準，設定的 GAP 太小，報警會增加，導致誤報率增加，GAP 設置過大，又會導致漏報。另外，很多數據指標的波動成周期性變化，通過經驗或者人工很難設定一個合適的 GAP。

對此，我們在趨勢預測的基礎上增加動態閾值，比如報警條件為趨勢預測曲線上下10%，這個百分比可以根據業務進行調整。

服務全景圖——兩個維度

假設對監控平台的要求是只允許一到兩個視圖，來清楚的展現服務監控狀態，把所有的需求和指標進行優先順序排序，可以抽取出兩個關鍵維度，即機器維度和服務維度。

機器維度

這個視圖下，我們的核心是要清楚確定所有機器的基本狀態，可以簡化為：健康、亞健康和病態三種。健康的狀態表示，機器資源使用（cpu、memory、netio、band、load 等）一切正常，可能未來一段時間（如 7 天）也會正常，機器使用者可以完全不用擔心這部分機器；亞健康狀態表示，機器資源存在一定風險，如高峰期網路 IO 太高，但仍然未達到影響機器正常運行的程度，機器使用者需要考慮機器 IO 類型或者擴容，以便應對短期可能產生的壓力；病態是指機器已經出現某個資源的消耗上限，如磁碟滿，需要機器使用者立即處理。

根據這樣的需求，我們需要設計的是這樣一個視圖，如圖7所示：

圖7 服務全景圖：機器維度

當某個機器有異常，能展示當前機器異常級別、時間及具體異常信息。

服務維度

在這個視圖下，我們關心的核心問題是，業務應用運行是否正常，整個鏈路是否通暢，是否有異常和告警，影響了多少節點。能夠查看命名空間下的所有關聯服務上下游整體健康狀態，針對異常節點可以展示異常原因和監控報表。

同時，結合自動化平台，將服務之間的上下游關係（拓撲圖）進行展示，如圖8所示。

圖8 服務全景圖：服務維度

智能恢復觸發器

恢復觸發器的功能是在某條報警被觸發時，由系統來進行一定程度的維護工作，比如降級或者遷移。其設定目標一定是要可擴展的，而且要能支持用戶自定義觸發器。

目前 Hubble 系統設計上只是簡單支持了類似服務 restart、reload、stop 等標準觸發器，還有不少的路要走。

後記

監控系統首要解決的問題是指標覆蓋率，大而全，在此基礎上做深耕，提高準確性，最後是精簡和抽象，發現數據後面最本質的東西。微博廣告基礎架構團隊在監控方面有一定的積累，並率先在監控中利用機器學習技術進行了一部分嘗試，未來將在智能預測和服務自動化處理（降級、恢復等）方面進行更深入的嘗試。

作者介紹

彭冬 Andrew

新浪微博商業產品部架構師，目前負責廣告核心引擎基礎架構、Hubble 系統、D+ 商業基礎數據平台建設及相關管理工作。關注於計算廣告、大數據、人工智慧、高可用系統架構設計。

IOTEP - 開放創新，崇尚技術，追求極致 Innovation and Open, Technical, Extremely Perfect

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！