1. 背景
1.目前中間件容器節點故障、機器資源不足(磁盤大小、內存大小、cpu)等問題時有發生，接入自動化運維後可快速的處理集羣異常問題。redis
2.之前處理問題須要人工介入，人力成本較大，運維流程缺少規範。windows
2. 目標
1. 標準化，規範運維流程，制定標準的運維流程。後端
2. 可視化，運維流程可視化、平臺化，作到可追蹤，可回溯。緩存
3. 自動化，容器重建，進程啓停，部分指標經過根因分析實現故障自愈。網絡
3. 故障自愈架構圖
故障自愈的監控數據採集模塊，週期性將採集到的各實例指標數據上報給處理器，處理器經過調用元數據模塊獲取匹配規則、故障自愈處理流。匹配異常數據成功並生成運維事件，再通過事件收斂過濾以確保沒有大批量相同屬性(如同業務、機房等)，最後執行對應編排的自愈處理流，運維事件恢復，發送通知，業務恢復正常。session
產品架構圖：架構
總體流程圖：併發
4. 方案設計
4.1 故障識別
經過拉取實例監控數據、多指標聚合檢測識別出異常，並觸發故障自動化流程。運維
方案一：過濾型檢測監控數據
過濾型檢測匹配，只跟數據自己有關，時間窗口設定沒有要求，數據來一條處理一條。達到設定的異常閾值時觸發運維事件。此檢測方案過於粗暴，對於一些監控數據存在瞬時突刺現象也會觸發誤運維，若頻繁自愈會影響中間件穩定性。此方案通常用於告警觸發，用做運維觸發存在必定風險。分佈式
方案二：基於窗口時間檢測
窗口選擇分類：
固定窗口(fixed windows):設置一個固定的時間長度，實時統計窗口時間內的數據。一般狀況會根據key作一些Partition劃分，這樣能夠作一些併發處理，加速計算。
滑動窗口(sliding windows):設置一個窗口長度和滑動長度，若是滑動長度小於窗口的長度，那麼就出現一部分窗口會互相覆蓋，部分數據存在重複計算；若是窗口長度等於執行週期，那麼就是固定窗口的模式；若是窗口長度小於執行週期，就是抽樣的計算了。
會話窗口(session windows): 針對的是具體的某個事件，好比特定的人看的視頻集合等。會話要等待的數據是不肯定何時到來的，窗口永遠是不規整的。
結論：週期性監控數據能夠看做相對規律且無窮的數據，故而前兩種窗口模式作流式計算比較適合。
窗口時間選擇：
基於計算時間的窗口處理問題是很是簡單的，只要關注窗口內的數據就能夠了，數據完整性也不用操心。可是實際的數據裏確定帶有事件時間，這個時間的數據一般在分佈式系統中也是無序的，要是系統出現某些點的延遲，那麼獲得的結果其準確性就大大下降了。基於事件時間對於業務準確性有很明顯的好處，可是也有很明顯的缺點，由於數據延遲，在分佈式系統很難說這段時間內，數據已經完整了。
數據完整性保障：
顯然不管窗口給的多大，永遠沒法保證，符合窗口內事件時間的數據必定可以準時到達，利用watermarks （水位線）能夠解決何時認爲數據結束關閉窗口進行計算的問題。以下圖：
設定固定窗口2分鐘聚合計算，獲得的4個窗口聚合結果分別是六、六、七、12，但在第一個窗口12:02聚合結束後，其實該窗口數據在12:03纔算完整完整，故而獲得的結果不許確，引入watermark可獲得正確的聚合結果11。這裏的watermark表示多長時間之前的數據將再也不更新，也就是說每次窗口聚合以前會進行watermark的計算，首先判斷此次聚合窗口最大事件時間，而後加上所能忍受的延遲時間就是watermark，當一組數據或新接收的數據事件時間大於watermark時，則該數據不會更新，可彈出窗口內的數據進行計算且在內存中再也不維護該組數據的狀態。
流式計算之固定窗口：
中間件監控數據週期性上報數據量不是很大，分佈式系統中對於輕量級流能夠考慮利用redis作實時聚合，並實現滾動窗口觸發。
如上圖所示，設定匹配的窗口大小爲2分鐘，容許數據最大延遲時間爲2分鐘，則watermark = 窗口時間的最大值+2，經過往redis緩存實時聚合兩個窗口結果便可完成窗口持續滾動，當事件時間大於window1窗口的watermark threshold 時間時，當即彈出window1窗口給process處理器判斷是否超過異常閾值，若超過則產生運維事件等待自愈，同時將第二個窗口window2的數據移動至第一個窗口window1中，從而實現持續滾動效果。
總結：滾動窗口占用緩存空間較少，聚合速度快，不足地方可能存在匹配不精準，若是設置窗口時間較大，聚合結果到達配置閾值的數據恰好位於兩個窗口相連的數據集中，此時是不會觸發運維事件的，其次多指標（一個監控指標對應一個固定窗口）匹配運維事件時，會存在多窗口到達水位線後的彈出時間對不齊的狀況，可能存在永遠匹配不上的狀況。這個時候還需增長窗口之間匹配等待來解決該問題。基於滑動窗口方式可解決以上兩個問題。
流式計算之滑動窗口：
多指標滑動窗口; DataEvent爲某個實例監控數據，每分鐘上報一次或屢次，數據包含3個指標項metrics一、metrics二、metrics3，若配置三個指標項週期聚合結果超過設定閥值則觸發運維事件，其週期窗口大小分別爲6分鐘、5分鐘、3分鐘，滑動窗口時間1分鐘，容許最大延遲時間爲1分鐘，則在12:08分後同時彈出三個窗口數據進行聚合匹配運維事件規則。同時窗口向前移動，再也不參與統計的數據則可不在緩存中維護，如上圖帶虛線的指標項數據。
4.2 事件收斂及自愈控制
事件收斂：
相同事件在短期內屢次發生，自愈事件可能會發生並行執行或在短期內屢次觸發。自愈每每會涉及到容器或者服務重啓，頻繁自愈影響集羣穩定性，對此可設置一個靜默時間對事件作收斂，靜默時間未過再也不往自愈服務發送事件。
自愈控制：
1.同一集羣下，集羣事件與實例事件互斥，即保證在同一時刻只容許集羣中的一個節點進行自愈行爲。若集羣中的實例都在自愈（如垂直擴容），則會致使集羣不可用。同集羣實例實現串行化自愈可經過MQ發送端利用集羣ID作路由到指定隊列上，消費端拉取隊列按順序消費完成。以下圖所示：
2.當有新節點添加/下線時，會給節點2分鐘的容忍時間，防止因爲節點剛剛添加到集羣/或下線的不穩定性致使錯誤自愈。
3.針對自愈解決不了的場景設置自愈次數上限，防止循環自愈，併發通知。
4.歷史過時事件過濾，每一個事件有過時時間，表示這個事件在發生多久後，會認爲過時，事件在決策流程時會先判斷是否有效，過時的事件不用再處理。
4.3 故障緣由分析
運維事件觸發回調進行故障分析，分析根本緣由，識別誤運維。拉取運維事件對應的根因分析策略，主要利用動態指標+決策樹實現自愈，整個分析自愈模塊可視化。指標：主要是監控項的指標，如系統負載、cpu使用率、內存使用率、網絡I/O、磁盤使用率、系統日誌、gc日誌等
e.g決策樹模型
e.g節點離線總結結論
4.4 故障自愈
利用根因分析及異常結論總結，在元數據模塊進行可視化的事件處理流程編排以及決策動做、執行動做的配置，當檢測到運維事件發生後，結合事先編排的事件處理流，並執行相關的流程動做，實現服務自愈效果。
節點異常處理流編排以下：
5. 總結
經過拉取監控數據，檢測匹配異常數據觸發運維事件，再結合編排的事件處理流自動完成一些比較繁瑣的自愈行爲，整個執行流程可視化、串行化。以上僅例舉節點異常事件編排，還可編排磁盤清理、擴容等運維場景，同時沉澱故障處理經驗造成知識庫，回溯過往發生的異常監控數據來提早發現問題，並處理潛在故障。
做者簡介
Carry OPPO高級後端工程師
目前在OPPO中間件團體負責中間件自動化運維的研發，關注分佈式調度、消息隊列、Redis等中間件技術。
更多精彩內容，請關注[OPPO數智技術]公衆號