百億業(yè)務流量-如何做好穩(wěn)定性監(jiān)控

監(jiān)控 -- 安全生產(chǎn)的第一戰(zhàn)線，報警的有效覆蓋率、線上問題的發(fā)現(xiàn)能力以及如何快速定位問題是監(jiān)控的核心能力。

安全生產(chǎn)整體目標1-5-10，1 分鐘發(fā)現(xiàn)問題、5 分鐘定位問題、10 分鐘修復問題。

JSTracker平臺 —?打造端到端的前端監(jiān)控與數(shù)據(jù)分析平臺，提供實時監(jiān)控、多端覆蓋、數(shù)據(jù)分析、智能化的核心能力，并基于?JSTracker平臺?來完成淘系雙11的穩(wěn)定性保障。

本篇文章將通過介紹我們是如何基于?JSTracker平臺?建設 1-5-10整體解決方案以及如何保障淘寶直播、會場、店鋪、互動、交易等多個核心業(yè)務的雙11大促穩(wěn)定性。

前端跨端方案不斷在演進，在前端框架上，覆蓋了web、weex、小程序等多種跨端方案場景，工程的基礎設施逐漸成熟，但業(yè)務整體的故障發(fā)現(xiàn)率依然偏低。對FY18-FY20淘系前端故障做了統(tǒng)計分析，監(jiān)控發(fā)現(xiàn)率均值低于30%, ?整體平均修復時長遠超過1個小時?，F(xiàn)從問題發(fā)現(xiàn)、快速恢復來分析下具體原因：

多數(shù)故障未及時發(fā)現(xiàn)，核心問題不是報警有效性的問題，大部分來自于被動通知，線上反饋、輿情或者客訴等，從問題分析來看存在以下幾個問題：

• 業(yè)務未接入監(jiān)控，安全意識缺乏以及基礎設施并不完備，頁面需要手動引入監(jiān)控SDK，很多業(yè)務在線上完全處于裸奔狀態(tài)

• 核心指標未訂閱，多數(shù)頁面引入了監(jiān)控但是沒有訂閱報警或者指標訂閱不完整，導致線上問題沒有第一時間發(fā)現(xiàn)

• 監(jiān)控指標不完整，從傳統(tǒng)前端視角，可能只會關注頁面運行時的異常，比如jserror、接口報錯運行等，但是從頁面整個運行過程來看，很多監(jiān)控指標是缺失的，比如cdn節(jié)點異常、頁面加載白屏、頁面執(zhí)行crash等問題

從故障平均恢復統(tǒng)計時長來看離目標10分鐘快速恢復存在很大差距。一個完整的開發(fā)流程包含 ：開發(fā) ?-> 發(fā)布 -> 線上驗證回歸流程。流程如圖所示：

如果問題已經(jīng)發(fā)布上線，按照發(fā)布流程很難做到10分鐘恢復，對于問題的核心解法，需要聚焦到頁面發(fā)布之前的開發(fā)階段和發(fā)布階段，主要涉及兩點：

• 發(fā)布之前：完整的自動化測試流程，例如在發(fā)布之前對資源異常、JSError等做檢測攔截

• 發(fā)布過程：頁面發(fā)布過程具有可灰度、可監(jiān)控、可回滾的完整過程

圍繞著 1-5-10 安全生產(chǎn)整體目標，針對“問題發(fā)現(xiàn)、快速恢復”的問題解決方案如下：

從故障問題來看，問題發(fā)現(xiàn)的核心問題是需要先解決監(jiān)控覆蓋率的問題，解決接入覆蓋、訂閱覆蓋、指標覆蓋的問題，保障業(yè)務100%接入和訂閱以及頁面的監(jiān)控指標完整性，具體解決方案如下：

接入覆蓋

我們需從兩個維度來解決接入覆蓋率的問題，完善基礎設施和業(yè)務治理推動的角度

• 完善基礎設施，前端頁面主要分為兩部分，源碼和搭建（斑馬、方舟）。在搭建層，我們在solution做了統(tǒng)一默認接入, 在源碼層，目前?集團監(jiān)控采集規(guī)范和數(shù)據(jù)規(guī)范標準還未統(tǒng)一，正在標準化統(tǒng)一的路上

• 業(yè)務治理推動，通過團隊維度統(tǒng)計覆蓋分布和指標情況，度量頁面安全分, 引導和推動業(yè)務快速完成接入

在業(yè)務治理層，需要建立指標統(tǒng)計和業(yè)務度量方式，方案如下

指標統(tǒng)計

在度量開發(fā)過程當中，需要各種維度來統(tǒng)計指標數(shù)據(jù)，比如團隊、時間等。如何高效的按匯報關系將數(shù)據(jù)進行匯總，是統(tǒng)計分析的核心問題，整體思路如下

• 構造人員工號的全路徑字段(工號路徑)，可以通過path節(jié)點找到層級關系

• 獲取某個主管下的列表，可以通過like快速查詢，比如獲取a3的所有員工, ?如：工號路徑 like '%a3%'

度量&紅黑榜

度量目標幫助業(yè)務、團隊做輔助決策，基于頁面的原始數(shù)據(jù)，從原始數(shù)據(jù) -> 數(shù)據(jù)分析 -> 指標度量 -> 業(yè)務決策 ，可建立一套指標度量模型，幫助業(yè)務快速發(fā)現(xiàn)問題

訂閱覆蓋

從統(tǒng)計數(shù)據(jù)可以看出, 很多頁面主要是指標訂閱不完整，比如只訂閱了jserror，忽略白屏、crash等指標的訂閱。在業(yè)務現(xiàn)狀下，需要對未訂閱的頁面補齊訂閱指標以及保障后續(xù)核心指標訂閱，整體流程如下：

• 訂閱指標補齊：通過治理流程，統(tǒng)計頁面未訂閱關系分布，走一鍵訂閱指標補齊

• 完善發(fā)布流程：頁面發(fā)布后，訂閱發(fā)布消息，對核心指標做增量訂閱

指標覆蓋

跨端頁面，從整體的頁面周期來看主要劃分為三個過程，從容器啟動 -> air渲染 -> 頁面加載執(zhí)行

• 容器層，比如weex、webview容器等，加載運行過程可以檢測頁面加載是否白屏、crash等

• 源站層，如果在cdn就出現(xiàn)異常，從前端的視角是無法感知的

• 頁面層，依賴本身SDK的能力，全局捕捉過程異常點作為監(jiān)控指標點

從安全視角來看，整個鏈路的穩(wěn)定性都需要做到可監(jiān)控。全鏈路保障過程，在數(shù)據(jù)鏈路層對數(shù)據(jù)指標過程做了統(tǒng)一接入，通過頁面地址對齊指標

快速恢復的核心是需要更快發(fā)現(xiàn)問題，更快的對變更進行回滾。歷史故障數(shù)據(jù)，80%左右的線上問題是由變更導致的。但很多故障不是缺少監(jiān)控導致的，而是新的版本變更引起的問題在整體的錯誤量不明顯，在整體日志層沒有區(qū)分，導致看到的表面現(xiàn)像是正常的，而忽略了問題。

對于變更的過程的監(jiān)控?【灰度監(jiān)控】，需要標識異常的日志是新的版本帶來的，用來對比線上版本的監(jiān)控區(qū)分出新版本的錯誤比例增長以及新引發(fā)的問題，解決方案如下：

• 指標采集：采集腳本通過讀取模板全局變量獲取，容器層通過response header拿到灰度標識

• 監(jiān)控指標：采集腳本和容器層需要統(tǒng)一和標準化灰度字段規(guī)范，在日志上報過程中攜帶，小程序通過版本號區(qū)分

• 灰度應用：主要表現(xiàn)在指標灰度實時日志呈現(xiàn)和報警

采集標準

主要分為兩部分：字段規(guī)范和集成規(guī)范。字段規(guī)范主要針對不同的日志源，在數(shù)據(jù)鏈路上處理字段統(tǒng)一；集成規(guī)范是對于不同的跨端場景，用于頁面識別灰度狀態(tài)

字段規(guī)范

集成規(guī)范

<meta name="page-tag" content="env=spe,grey=true,version=0.0.1" />

采集方式

通過采集方式解決頁面監(jiān)控SDK以及跨端容器（weex、windvane等）獲取發(fā)布版本的信息的問題，主要存在以下兩個問題

• 監(jiān)控SDK：受瀏覽器的限制，只能通過全局的方式讀取，比如通過meta標簽或者全局變量的方式

• 跨端容器：獲取不到模板的內(nèi)容，只能通過響應頭的信息來獲取到版本信息

基于上面問題，和前端發(fā)布約定下面兩種標準的方式來通知端當前發(fā)布狀態(tài)

• 集成到response headers內(nèi)容里，headers里面寫入版本號、灰度狀態(tài)

• 直接在渲染層注入到頁面模板內(nèi)容，模板渲染的時候可以寫入到全局參數(shù)中

具體方式

• web sdk， 考慮全局變量存在一定污染，目前標準集成是通過meta標簽的方式

"" content="{{$page.isGreyPage}}" />

• 容器側，直接讀取到response內(nèi)容，但是也存在弊端，依賴客戶端發(fā)版迭代

灰度應用

從監(jiān)控視角來看，一個新的版本迭代主要擔心兩點，會不會帶來新的問題或錯誤率比例會不會變大。對于應用側，需要讓用戶清晰的感知指標的變化情況，具體如下：

灰度監(jiān)控報警

灰度報警鏈路如下圖：

1、訂閱頁面的發(fā)布消息，存儲或者刪除頁面發(fā)布的信息，比如頁面地址、灰度比例、發(fā)布人等配置信息

2、灰度報警目前是通過5分鐘進行一次輪詢，灰度版本日志可以拉取最新30分鐘，線上可以拉取12個小時日志，避免新增的日志誤差比較大造成誤差，在對日志進行diff比較，相似度 < 50% 判斷為新增日志，效果如下：

灰度實時監(jiān)控

指標采集完整之后，在指標日志增加grey字段對灰度版本以及線上版本做日志區(qū)分，可以通過對比以下幾點來判斷灰度版本是否異常

• 灰度版本錯誤率和線上版本錯誤率的比例值

• 錯誤日志的趨勢比例以及狀態(tài)

目前淘系C端的頁面監(jiān)控覆蓋率是98%, 包含源碼頁面、搭建頁面以及小程序。以主會場監(jiān)控為例，在預售、預熱、正式階段，直接定位到?10+?處模塊開發(fā)問題。

監(jiān)控大屏

基于頁面監(jiān)控、指標覆蓋率的完整前提下，通過datav搭建了淘系整體的監(jiān)控大盤，可以全局觀察核心頁面的異常情況。

案例: ?雙11晚上，整體的weex錯誤日志上漲，通過日志排查是有個頁面js執(zhí)行錯誤的邏輯

指標覆蓋

Crash日志?整體上漲，xx號客戶端推送配置，Crash日志大量上漲，業(yè)務第一時間收到報警，及時止血

灰度監(jiān)控

互動業(yè)務，新增功能迭代發(fā)布后，灰度報錯異常比例增加，及時回滾避免了線上問題擴大

在監(jiān)控覆蓋、灰度監(jiān)控等能力建設之下，我們有了更好規(guī)避問題和感知問題的能力，才能讓業(yè)務走的更遠、走的更快。目前在報警訂閱、準確性、指標分析上仍然存在不少問題，后續(xù)我們會持續(xù)完善監(jiān)控的能力，歡迎一起討論交流。

喜歡就點這里