Goldeneye作為阿裡媽媽業務監控平臺，主要在業務日誌、資料的實時統計分析基礎上做監控報警以及輔助定位。阿裡集團內部也有很多優秀的監控平臺，它們在開放性上做的很好，接入成本也不高，但是監控閾值也是開放給使用者自己設定。

這種情況下，對於業務監控人工維護閾值就比較複雜，需要有豐富的經驗來拍定閾值，需要人工持續的維護不同監控項的監控閾值。所以，在業務快速發展的前提下，傳統的靜態閾值監控很容易出現了誤報、漏報的問題，而且人工維護成本高，監控視野侷限。Goldeneye就是在這種基礎上，我們試著從大資料應用的角度，去解決業務監控中的問題，由此誕生的。

1. 業務背景：

(1)體量大：Goldeneye現在接入的業務線改寫了阿裡媽媽主體的90%業務，每天處理的日誌量在100T以上，業務監控需要對各業務線的流量分層級實時監控，核心資料以1分鐘為週期，一般監測資料以5分鐘或1小時為週期，監控標的非常多，按人工維護這些監控的閾值、啟停、生效實效等幾乎是達不到的。

(2)變化多：業務監控的監測資料大都是業務指標，不同於系統運維指標，比如RT/QPS/TPS等一般是比較穩定的，業務指標具有周期性變化的特點，比如工作日和節假日的區別、業務營銷策略調整的影響等，在這種情況下人工設定的靜態報警閾值準確性就很難保障了。

(3)迭代快：隨著阿裡媽媽資源整合和業務的快速發展，監控標的也經常發生變化，比如流量監控資源位的調整、效果監控的產品型別劃分等，曾經出現過新流量上線後的監控盲點。

2. 技術背景：

圖1 Goldeneye技術背景

通常的業務監控系統或平臺，都是由採集、資料處理、檢測、報警等模組組成的，Goldeneye也是如此，不過它的技術架構上用了阿裡內部的一些技術中介軟體，比如採集我們使用Time Tunnel(它有agent在各臺日誌伺服器上拉日誌到Topic，並且負責將離線日誌放到ODPS上)，這部分我不再介紹了。

資料處理我們使用的jstorm和ODPS MR job分別對日誌進行實時、離線批處理，主要包括日誌解析、校驗、時間週期歸一化、聚合、寫儲存(HBase)等操作，這部分下一期分享中我的同事會詳細介紹。今天的分享主要集中在閾值預測、監控檢測、報警生成&通知、輔助定位這四部分。

一、技術思想

智慧監控就是讓系統在業務監控的某些環節上代替人工執行和判斷的過程。人工維護監控標的和閾值是以經驗為參考的，系統如何自動判斷哪些標的需要監控、自動設定監控標的的閾值水位、不用人力維護，是基於對歷史樣本資料統計分析得出判斷依據。

透過收集監測資料的樣本，並使用智慧檢測演演算法模型，讓程式自動對監控項指標的基準值、閾值做預測，在檢測判斷異常報警時使用規則組合和均值漂移演演算法，能精確地判斷需要報警的異常點和變點。

1.閾值水位自適應變化

以往我們新增監控有兩種做法。第一種是給指標M1設定一個水位線，低於（或高於）水位，觸發報警；另一種是給指標M1設定同比、環比波動幅度，比如同比波動20%、環比波動10%觸發報警。

以上兩種方式，是平常大家常用的監控方式，但是效果確不理想，這種靜態閾值長期來看沒有適應變化的能力，需要人工維護，而且報警準確性也依賴於同環比資料的穩定性。

我們能否讓系統具備自動適應變化的能力，自動調整閾值水位？就如同手動擋的汽車換成自動擋一樣，可以根據速度自己調節檔位。

2.監控項自動發現

當我們的監控系統具備預測動態閾值的能力後，監控項的維護是否也可以交給系統去做？

可能大家也曾遇到過類似的情況，舊的監控項已經沒有資料了，新的監控標的卻因為各種原因被漏掉，人工維護監控項需要及時同步上下線變更，但是當我們需要監控的標的有一千個、一萬個甚至更多的時候，人力是無法一直跟進這些監控項的維護工作的，或者說這種工作比較單調容易被忽視。

我們能否將判斷如何篩選監控項的規則交給系統，讓它去定期檢查哪些監控項已經實效，哪些監控項需要新增，哪些監控項的閾值需要調節。這種發現規則是穩定的，僅僅是依據發現規則得出的監控項內容在不斷變化而已。

3.過濾誤報時欲擒故縱

當我們的監控系統具備預測動態閾值、自動發現並維護監控項的能力後，如何達到不漏報和不誤報之間的平衡？

對於監控而言，漏報是不可容忍的，但是誤報過多也容易使人麻木。

通常的做法是為了不被誤報幹擾至麻木，會把閾值調節得寬鬆些，但是這種做法容易產生漏報，尤其是下跌不太明顯的情況。

Goldeneye採取的思路是對誤報case欲擒故縱，在首先確保不漏報的基礎上降低誤報率。先監控產生疑似異常點，這一環節我們基於動態閾值去檢測時相對嚴格一些（或者說這一環節不用考慮報警收斂的問題），然後對這些疑似異常點再做驗證、過濾，最終生成報警通知，驗證和過濾的依據是預先定義的規則，比如指標組合判斷、報警收斂運算式等。

二、技術實現細節

下麵介紹技術實現的一些細節，分為監控系統的架構、動態閾值、變點檢測、智慧全景、輔助定位五個點。

1、整體介紹

Goldeneye監控系統的四個輸入：實時監測資料、歷史資料、預測策略、報警過濾規則。

其中，歷史資料是實時監測資料的積累。而預測策略主要包括：

（1）閾值引數：設定基於預測基準值的繫數決定閾值上下限區間、分時段閾值預測繫數、分報警靈敏度閾值預測繫數；

（2）預測引數：樣本數量、異常樣本過濾的高斯函式水位或者過濾比例、基於均值漂移模型的樣本分段選取置信度等。

關於報警過濾規則，主要是為了在充分捕捉疑似異常點的前提下，過濾不必要的報警。比如指標M1異常，但是組合規則是M1和M2同時異常才報警，這種就會過濾掉。

再比如，按照報警收斂規則，一個監控項的第1次，第2次，第10次，第50次連續報警值得關註，可以設定收斂運算式為1、2、10、50，那麼在報警通知生成時對於第3、4、…、9、11、12、…、49次報警可以忽略，因為反覆通知的意義不大，這個規則可以按需要達到自動收斂。也可以在同一監控項的多個實體同時發生異常報警的情況下，按規則合併成一條報警，這些規則可以按具體情況去實現，最終的目的是以最簡潔的方式暴露最值得關註的報警。

這裡補充一句，我們最近在考慮新的收斂方式，對第1條和最後1條報警，並且自動計算出累積gap，這樣異常的起止和影響範圍更明顯。

圖2 Goldeneye報警系統架構

2、動態閾值

監控使用控製圖，對監測指標的時間序列視覺化，讓人們可以清楚的看到指標的波動。基於控製圖的監控，以往很多都是靜態閾值方式，比如前面提到的靜態水位線、同環比。動態閾值是為控製圖的時間序列每個點，預估該點對應時刻這個指標的基準值、閾值上限、閾值下限，從而讓程式可以自動判斷是否有異常。

因為這種預估基於過去幾個月甚至更多的歷史樣本作為參考，所以比同環比兩個資料作為參照的準確度要高。動態閾值預測的理論基礎是高斯分佈和均值漂移模型。

圖3 動態閾值原理

動態閾值預測的步驟主要是這樣的:

（1）樣本選取：這個根據自己的需要，一般建議選取過去50天左右的樣本。

（2）異常樣本篩除：這個過程主要使用高斯分佈函式過濾掉函式值小於0.01，或者標準方差絕對值大於1的樣本。

（3）樣本擷取：因為後來我們最佳化的版本，在第2步的基礎上使用均值漂移模型對歷史樣本在時間序列上進行分段檢驗，如果有周期性變化、或者持續單調變化，則會反覆迭代均值漂移模型尋找均值漂移點，然後擷取離當前日期最近第一段(或者可以理解為最近一段時間最平穩的樣本序列)。

樣本選取還有一個需要註意的問題，節假日和工作日的樣本要分開選取，預測工作日的閾值要選擇工作日的樣本，節假日亦然，也就是對預測樣本從日期、週末、平穩性三個維度拆分選取。

（4）預測基準值：經過步驟2和3的篩選、擷取，剩下的樣本基本上是最理想的樣本了，在此基礎上，保持樣本在日期上的順序，按指數平滑法預測標的日期的基準值，得到基準值以後根據靈敏度或閾值繫數，計算閾值上下限。

補充說明：第四步預測基準值，有些人可能之前用過指數平滑法預測，跟第四步我們在樣本權重加權時的做法很相近，但是他們預測的效果不理想，因為對樣本整體沒有充分的過濾選取最穩定的樣本集合。

3、變點檢測

動態閾值用資料統計分析的辦法解決了靜態閾值的誤報漏報問題，節省了人工維護的成本，一定程度上降低了監控風險。不過在微量波動、持續陰跌的故障面前，動態閾值也有侷限性，閾值區間收的太緊誤報會增多，區間寬鬆就會漏報一些不太顯著的故障。

在review漏報case時，我們從控製圖上發現這些微量波動肉眼可以觀察到趨勢，但是程式透過閾值區間擊穿的判斷方式很難控制，所以引入了均值漂移模型來尋找變點。所謂變點，就是持續微量下跌到一定時間，累積變化量到一定程度後，使得變點前後監測指標在一段時間內的均值發生漂移。

圖4 均值漂移原理

從上圖可以看到，均值漂移模型的演演算法原理，實際上是把程式不容易識別的陰跌趨勢，轉換成CUSUM時間序列，它的趨勢很明顯，在變點左側單調增、右側單調減，CUSUM時間序列描述了被監測時間序列每個點偏離均值的累積變化量，它的規律是從S0=0開始，到Sn=0結束，變點兩側單調變化。

CUSUM＝Cumulative Sum。累積和用以在某個相對穩定的資料序列中，檢測出開始發生異常的資料點。累積和最典型的應用是在“改變檢測”(Change Detection)中對參量變化的檢測問題轉化了以後，用程式求CUSUM序列上每個點的一階導數，從持續增變為持續減即可判定為變點，至於持續增、減多少個點，由自己來設定。

關於變點檢測使用的mean-shift模型，大家可以去網上找找paper，我這臺電腦上找不到了，上面主要說明瞭發現變點的原理，通俗地講，就是把問題轉化成程式容易解決的狀態陰跌執行緒序不容易量化衡量、判斷，那麼就用CUSUM控製圖裡的“富士山”形狀去尋找，這是我個人的通俗解釋。

上面說到我們使用CUSUM序列上每個點的一階導數來判斷拐點（變點）是否到來，其實圖上這個例子是比較理想的情況，在我應用mean-shift模型時，遇到了一些複雜情況，比如這個圖上就一個“山頭尖”，但是也時候會有多個，這種情況下就要再次轉化問題，比如可以把CUSUM再差分，或者以我們的做法，記錄一階導數的狀態值，從連續N個正值變為持續N個負值時可以判定。

另外，變點檢測的演演算法實現我這裡不方便詳細說明，其中變點在反覆迭代時自己可以根據實際情況設定迭代次數和置信度，有助於提高變點發現的準確性。

4、智慧全景

變點檢測彌補了動態閾值對細微波動的檢測不足，這兩種方式結合起來，基本可以達到不漏報和不誤報的平衡，同時也不需要人工長期維護，這是智慧全景監控的基礎。當監控的人力成本節省了以後，理論上我們可以依賴智慧監控無限制的開拓監控視野，並將這些監控報警連結起來分析。

監控項的自動發現規則，比如對維度D的指標M做實時監控，維度D下可能由1000種維度值，而且是不斷變化的1000種，如何讓程式自動維護監控項？你可以制定一個規則，比如指標M>X則認為需要監控（畢竟不是所有的都需要監控報警，至少在目前故障定位處理沒有完全自動化的狀況下，報警處理也是需要一定人力的）。在滿足M>X的條件下，為了提高報警準確性，我們還需要根據重要性區分報警靈敏度，也就是對於宏觀、核心的維度值我們希望能夠非常靈敏的監控波動，而對於非重要的維度值我們預測閾值可以寬鬆一些，這些可以透過上面說的閾值引數來設定。

說明: 這個規則我這裡只是舉一個例子，各位同仁可以根據自己的實際場景去實現一些規則，比如系統運維層面的監控，有些是按照距離故障發生的速度或風險繫數來判斷，那麼就可以圍繞這種指標來制定，假如是對磁碟利用率的監控，就是容量增長速度與剩餘資源比例作為參考等等。

以上條件都滿足了之後，智慧全景監控基本可以執行，不過我們也曾遇到一些其他的問題，比如業務方需要接入監控，但是不一定是必須要我們解析日誌，他們有自己的資料，可能是資料庫、介面傳回、訊息中介軟體裡的訊息等等。

所以，我們在資料接入上採用分層接入，可以從日誌標準輸出格式、儲存的時間序列schema約定、閾值預測的介面三個層次接入使用，這個內容將在下一次分享時由我的同事單獨介紹。這裡之所以提到，是因為全景監控接入的資料比較多，所以接入途徑要有層次、靈活性。

5、輔助定位

報警的最終目的是減少損失，所以定位問題原因尤為重要。Goldeneye嘗試著用程式去執行人工定位原因時的套路，當然這些套路目前是透過配置生成的，還沒有達到機器學習得出來的地步，不過當業務監控指標接入的越來越多，指標體系逐漸完善以後，透過統計學的相關性分析，這些套路的生成也有可能讓程式去完成。這裡我介紹一下，程式可以執行的人工總結處的幾個套路。

（1）全鏈路分析

從技術架構、業務流程的角度，我們的監測指標是否正常，從外部因素分析，一般會受到它的上游影響。按照這個思路，逐一分析上游是否正常，就形成了一條鏈路。這種例子很多，比如系統架構的模組A、B、C、D、E的QPS。

圖5 全鏈路tracing

插一句，全鏈路分析有兩種資料記錄方式，要麼鏈路每個節點內部透傳，拼接成完整鏈路處理資訊記錄到最終的節點日誌；要麼非同步地每個節點各自將資訊push到中介軟體。

（2）報警時間點上發生了什麼？

這是收到監控報警後大多數人的反應，我們把運維事件、運營調整事件盡可能地收集起來，將這些事件地散點圖和監測報警的控製圖結合起來，就能看出問題。如果程式自動完成，就是將事件發生的時間點也按相同的方式歸一化到固定週期的時間點，檢查與報警時間點是否吻合。

圖6生產事件與時間序列

（3）A/B test或TopN

有些人定位問題，使用排除法縮小出問題的範圍。比如在維度D上指標M有異常波動，可以將D拆分成D1，D2，D3來對比，常見的具體情況比如機房對照、分組對照、版本對照、終端型別對照等等，如果在監測資料層級清晰的基礎上，我們可以一層一層的鑽取資料做A/B test，直到定位到具體原因。還有一種方式，不是透過列舉切分做A/B test，而是直接以指標M為標的，列出維度D的子維度D1，D2，D3，……中指標M的TopN，找出最突出的幾項重點排查。

圖7 A/B test or TopN

TopN也是類似的。大家可以也能看出來，智慧監控和輔助定位是需要一個清晰的資料層級和元資料管理系統來支撐的，這一點很基礎。

（4）關聯指標

不同的指標在監控中都是持續的時間序列，有些指標之間是函式關係，比如ctr=click/pv，click和pv的變化必然帶來ctr的變化，這種聯絡是函式直接描述的。還有一些指標的關聯，無法用函式公式描述，它們之間的相關性用統計學指標來衡量，比如皮爾遜繫數。

Goldeneye的指標關聯依據，目前還沒有自動分析，暫時是人工根據經驗設定的，只是檢視讓程式去完成追蹤定位的過程，比如指標M1出現異常報警後能夠觸發相關指標RMG1/ RMG2/ RMG3的檢測（因為這些指標可能平時不需要7*24小時監控報警，僅在需要的時候check），以此類推逐級檢測定位。

圖8 關聯指標

這些方式或許大家平時也嘗試著去做過一些程式化的處理，我個人認為關聯指標的方式，基礎在於構建指標體系，這個構建過程可以是人工經驗和程式統計分析的結合，指標體系至少能夠描述指標的分類、資料出處、具體含義、影響相關指標的權重等等，有了這些基礎才能應用統計學的分析方法完成。

高效能運算知識星球

1、專註高效能運算技術、產品和解決方案。在這裡，除了提問，你還可以檢視各個知識點討論和答覆，構建業界知名高效能運算知識星球。

2、探討高效能運算行業趨勢(市場空間、技術趨勢)，解決方案(儲存、伺服器、網路等)，行業趨勢(傳統HPC，HPDA，HyperScale等)，主流產品(DDN、IBM、希捷、Panasas、HP、Intel等)，諮詢(技術、方案等)等。

3、年費包括“HPC從入門到精通12講”課程(待上線)。

掃碼加入

溫馨提示：

請搜尋“ICT_Architect”或“掃一掃”二維碼關註公眾號，點選原文連結獲取更多電子書詳情。

求知若渴, 虛心若愚