百億業(yè)務(wù)流量-如何做好穩(wěn)定性監(jiān)控
NO.1
前言
監(jiān)控 -- 安全生產(chǎn)的第一戰(zhàn)線，報(bào)警的有效覆蓋率、線上問題的發(fā)現(xiàn)能力以及如何快速定位問題是監(jiān)控的核心能力。
安全生產(chǎn)整體目標(biāo)1-5-10，1 分鐘發(fā)現(xiàn)問題、5 分鐘定位問題、10 分鐘修復(fù)問題。
JSTracker平臺(tái) —?打造端到端的前端監(jiān)控與數(shù)據(jù)分析平臺(tái)，提供實(shí)時(shí)監(jiān)控、多端覆蓋、數(shù)據(jù)分析、智能化的核心能力，并基于?JSTracker平臺(tái)?來完成淘系雙11的穩(wěn)定性保障。
本篇文章將通過介紹我們是如何基于?JSTracker平臺(tái)?建設(shè) 1-5-10整體解決方案以及如何保障淘寶直播、會(huì)場(chǎng)、店鋪、互動(dòng)、交易等多個(gè)核心業(yè)務(wù)的雙11大促穩(wěn)定性。
NO.2
現(xiàn)狀
前端跨端方案不斷在演進(jìn)，在前端框架上，覆蓋了web、weex、小程序等多種跨端方案場(chǎng)景，工程的基礎(chǔ)設(shè)施逐漸成熟，但業(yè)務(wù)整體的故障發(fā)現(xiàn)率依然偏低。對(duì)FY18-FY20淘系前端故障做了統(tǒng)計(jì)分析，監(jiān)控發(fā)現(xiàn)率均值低于30%, ?整體平均修復(fù)時(shí)長遠(yuǎn)超過1個(gè)小時(shí)。現(xiàn)從問題發(fā)現(xiàn)、快速恢復(fù)來分析下具體原因：
問題發(fā)現(xiàn)
多數(shù)故障未及時(shí)發(fā)現(xiàn)，核心問題不是報(bào)警有效性的問題，大部分來自于被動(dòng)通知，線上反饋、輿情或者客訴等，從問題分析來看存在以下幾個(gè)問題：
業(yè)務(wù)未接入監(jiān)控，安全意識(shí)缺乏以及基礎(chǔ)設(shè)施并不完備，頁面需要手動(dòng)引入監(jiān)控SDK，很多業(yè)務(wù)在線上完全處于裸奔狀態(tài)
核心指標(biāo)未訂閱，多數(shù)頁面引入了監(jiān)控但是沒有訂閱報(bào)警或者指標(biāo)訂閱不完整，導(dǎo)致線上問題沒有第一時(shí)間發(fā)現(xiàn)
監(jiān)控指標(biāo)不完整，從傳統(tǒng)前端視角，可能只會(huì)關(guān)注頁面運(yùn)行時(shí)的異常，比如jserror、接口報(bào)錯(cuò)運(yùn)行等，但是從頁面整個(gè)運(yùn)行過程來看，很多監(jiān)控指標(biāo)是缺失的，比如cdn節(jié)點(diǎn)異常、頁面加載白屏、頁面執(zhí)行crash等問題
快速恢復(fù)
從故障平均恢復(fù)統(tǒng)計(jì)時(shí)長來看離目標(biāo)10分鐘快速恢復(fù)存在很大差距。一個(gè)完整的開發(fā)流程包含 ：開發(fā) ?-> 發(fā)布 -> 線上驗(yàn)證回歸流程。流程如圖所示：
如果問題已經(jīng)發(fā)布上線，按照發(fā)布流程很難做到10分鐘恢復(fù)，對(duì)于問題的核心解法，需要聚焦到頁面發(fā)布之前的開發(fā)階段和發(fā)布階段，主要涉及兩點(diǎn)：
發(fā)布之前：完整的自動(dòng)化測(cè)試流程，例如在發(fā)布之前對(duì)資源異常、JSError等做檢測(cè)攔截
發(fā)布過程：頁面發(fā)布過程具有可灰度、可監(jiān)控、可回滾的完整過程
NO.3
整體方案
圍繞著 1-5-10 安全生產(chǎn)整體目標(biāo)，針對(duì)“問題發(fā)現(xiàn)、快速恢復(fù)”的問題解決方案如下：
監(jiān)控覆蓋
從故障問題來看，問題發(fā)現(xiàn)的核心問題是需要先解決監(jiān)控覆蓋率的問題，解決接入覆蓋、訂閱覆蓋、指標(biāo)覆蓋的問題，保障業(yè)務(wù)100%接入和訂閱以及頁面的監(jiān)控指標(biāo)完整性，具體解決方案如下：
接入覆蓋
我們需從兩個(gè)維度來解決接入覆蓋率的問題，完善基礎(chǔ)設(shè)施和業(yè)務(wù)治理推動(dòng)的角度
完善基礎(chǔ)設(shè)施，前端頁面主要分為兩部分，源碼和搭建（斑馬、方舟）。在搭建層，我們?cè)趕olution做了統(tǒng)一默認(rèn)接入, 在源碼層，目前?集團(tuán)監(jiān)控采集規(guī)范和數(shù)據(jù)規(guī)范標(biāo)準(zhǔn)還未統(tǒng)一，正在標(biāo)準(zhǔn)化統(tǒng)一的路上
業(yè)務(wù)治理推動(dòng)，通過團(tuán)隊(duì)維度統(tǒng)計(jì)覆蓋分布和指標(biāo)情況，度量頁面安全分, 引導(dǎo)和推動(dòng)業(yè)務(wù)快速完成接入
在業(yè)務(wù)治理層，需要建立指標(biāo)統(tǒng)計(jì)和業(yè)務(wù)度量方式，方案如下
指標(biāo)統(tǒng)計(jì)
在度量開發(fā)過程當(dāng)中，需要各種維度來統(tǒng)計(jì)指標(biāo)數(shù)據(jù)，比如團(tuán)隊(duì)、時(shí)間等。如何高效的按匯報(bào)關(guān)系將數(shù)據(jù)進(jìn)行匯總，是統(tǒng)計(jì)分析的核心問題，整體思路如下
構(gòu)造人員工號(hào)的全路徑字段(工號(hào)路徑)，可以通過path節(jié)點(diǎn)找到層級(jí)關(guān)系
獲取某個(gè)主管下的列表，可以通過like快速查詢，比如獲取a3的所有員工, ?如：工號(hào)路徑 like '%a3%'
度量&紅黑榜
度量目標(biāo)幫助業(yè)務(wù)、團(tuán)隊(duì)做輔助決策，基于頁面的原始數(shù)據(jù)，從原始數(shù)據(jù) -> 數(shù)據(jù)分析 -> 指標(biāo)度量 -> 業(yè)務(wù)決策 ，可建立一套指標(biāo)度量模型，幫助業(yè)務(wù)快速發(fā)現(xiàn)問題
訂閱覆蓋
從統(tǒng)計(jì)數(shù)據(jù)可以看出, 很多頁面主要是指標(biāo)訂閱不完整，比如只訂閱了jserror，忽略白屏、crash等指標(biāo)的訂閱。在業(yè)務(wù)現(xiàn)狀下，需要對(duì)未訂閱的頁面補(bǔ)齊訂閱指標(biāo)以及保障后續(xù)核心指標(biāo)訂閱，整體流程如下：
訂閱指標(biāo)補(bǔ)齊：通過治理流程，統(tǒng)計(jì)頁面未訂閱關(guān)系分布，走一鍵訂閱指標(biāo)補(bǔ)齊
完善發(fā)布流程：頁面發(fā)布后，訂閱發(fā)布消息，對(duì)核心指標(biāo)做增量訂閱
NO.3
指標(biāo)覆蓋
跨端頁面，從整體的頁面周期來看主要?jiǎng)澐譃槿齻€(gè)過程，從容器啟動(dòng) -> air渲染 -> 頁面加載執(zhí)行
容器層，比如weex、webview容器等，加載運(yùn)行過程可以檢測(cè)頁面加載是否白屏、crash等
源站層，如果在cdn就出現(xiàn)異常，從前端的視角是無法感知的
頁面層，依賴本身SDK的能力，全局捕捉過程異常點(diǎn)作為監(jiān)控指標(biāo)點(diǎn)
從安全視角來看，整個(gè)鏈路的穩(wěn)定性都需要做到可監(jiān)控。全鏈路保障過程，在數(shù)據(jù)鏈路層對(duì)數(shù)據(jù)指標(biāo)過程做了統(tǒng)一接入，通過頁面地址對(duì)齊指標(biāo)
灰度監(jiān)控
快速恢復(fù)的核心是需要更快發(fā)現(xiàn)問題，更快的對(duì)變更進(jìn)行回滾。歷史故障數(shù)據(jù)，80%左右的線上問題是由變更導(dǎo)致的。但很多故障不是缺少監(jiān)控導(dǎo)致的，而是新的版本變更引起的問題在整體的錯(cuò)誤量不明顯，在整體日志層沒有區(qū)分，導(dǎo)致看到的表面現(xiàn)像是正常的，而忽略了問題。
對(duì)于變更的過程的監(jiān)控?【灰度監(jiān)控】，需要標(biāo)識(shí)異常的日志是新的版本帶來的，用來對(duì)比線上版本的監(jiān)控區(qū)分出新版本的錯(cuò)誤比例增長以及新引發(fā)的問題，解決方案如下：
指標(biāo)采集：采集腳本通過讀取模板全局變量獲取，容器層通過response header拿到灰度標(biāo)識(shí)
監(jiān)控指標(biāo)：采集腳本和容器層需要統(tǒng)一和標(biāo)準(zhǔn)化灰度字段規(guī)范，在日志上報(bào)過程中攜帶，小程序通過版本號(hào)區(qū)分
灰度應(yīng)用：主要表現(xiàn)在指標(biāo)灰度實(shí)時(shí)日志呈現(xiàn)和報(bào)警
采集標(biāo)準(zhǔn)
主要分為兩部分：字段規(guī)范和集成規(guī)范。字段規(guī)范主要針對(duì)不同的日志源，在數(shù)據(jù)鏈路上處理字段統(tǒng)一；集成規(guī)范是對(duì)于不同的跨端場(chǎng)景，用于頁面識(shí)別灰度狀態(tài)
字段規(guī)范
集成規(guī)范
<meta name="page-tag" content="env=spe,grey=true,version=0.0.1" />采集方式
通過采集方式解決頁面監(jiān)控SDK以及跨端容器（weex、windvane等）獲取發(fā)布版本的信息的問題，主要存在以下兩個(gè)問題
監(jiān)控SDK：受瀏覽器的限制，只能通過全局的方式讀取，比如通過meta標(biāo)簽或者全局變量的方式
跨端容器：獲取不到模板的內(nèi)容，只能通過響應(yīng)頭的信息來獲取到版本信息
基于上面問題，和前端發(fā)布約定下面兩種標(biāo)準(zhǔn)的方式來通知端當(dāng)前發(fā)布狀態(tài)
集成到response headers內(nèi)容里，headers里面寫入版本號(hào)、灰度狀態(tài)
直接在渲染層注入到頁面模板內(nèi)容，模板渲染的時(shí)候可以寫入到全局參數(shù)中
具體方式
web sdk， 考慮全局變量存在一定污染，目前標(biāo)準(zhǔn)集成是通過meta標(biāo)簽的方式
"" content="{{$page.isGreyPage}}" />容器側(cè)，直接讀取到response內(nèi)容，但是也存在弊端，依賴客戶端發(fā)版迭代
灰度應(yīng)用
從監(jiān)控視角來看，一個(gè)新的版本迭代主要擔(dān)心兩點(diǎn)，會(huì)不會(huì)帶來新的問題或錯(cuò)誤率比例會(huì)不會(huì)變大。對(duì)于應(yīng)用側(cè)，需要讓用戶清晰的感知指標(biāo)的變化情況，具體如下：
灰度監(jiān)控報(bào)警
灰度報(bào)警鏈路如下圖：
1、訂閱頁面的發(fā)布消息，存儲(chǔ)或者刪除頁面發(fā)布的信息，比如頁面地址、灰度比例、發(fā)布人等配置信息
2、灰度報(bào)警目前是通過5分鐘進(jìn)行一次輪詢，灰度版本日志可以拉取最新30分鐘，線上可以拉取12個(gè)小時(shí)日志，避免新增的日志誤差比較大造成誤差，在對(duì)日志進(jìn)行diff比較，相似度 < 50% 判斷為新增日志，效果如下：
灰度實(shí)時(shí)監(jiān)控
指標(biāo)采集完整之后，在指標(biāo)日志增加grey字段對(duì)灰度版本以及線上版本做日志區(qū)分，可以通過對(duì)比以下幾點(diǎn)來判斷灰度版本是否異常
灰度版本錯(cuò)誤率和線上版本錯(cuò)誤率的比例值
錯(cuò)誤日志的趨勢(shì)比例以及狀態(tài)
結(jié)果
目前淘系C端的頁面監(jiān)控覆蓋率是98%, 包含源碼頁面、搭建頁面以及小程序。以主會(huì)場(chǎng)監(jiān)控為例，在預(yù)售、預(yù)熱、正式階段，直接定位到?10+?處模塊開發(fā)問題。
監(jiān)控大屏
基于頁面監(jiān)控、指標(biāo)覆蓋率的完整前提下，通過datav搭建了淘系整體的監(jiān)控大盤，可以全局觀察核心頁面的異常情況。
案例: ?雙11晚上，整體的weex錯(cuò)誤日志上漲，通過日志排查是有個(gè)頁面js執(zhí)行錯(cuò)誤的邏輯
指標(biāo)覆蓋
Crash日志?整體上漲，xx號(hào)客戶端推送配置，Crash日志大量上漲，業(yè)務(wù)第一時(shí)間收到報(bào)警，及時(shí)止血
灰度監(jiān)控
互動(dòng)業(yè)務(wù)，新增功能迭代發(fā)布后，灰度報(bào)錯(cuò)異常比例增加，及時(shí)回滾避免了線上問題擴(kuò)大
NO.4
總結(jié)
在監(jiān)控覆蓋、灰度監(jiān)控等能力建設(shè)之下，我們有了更好規(guī)避問題和感知問題的能力，才能讓業(yè)務(wù)走的更遠(yuǎn)、走的更快。目前在報(bào)警訂閱、準(zhǔn)確性、指標(biāo)分析上仍然存在不少問題，后續(xù)我們會(huì)持續(xù)完善監(jiān)控的能力，歡迎一起討論交流。
歡迎關(guān)注東半球最大的前端團(tuán)隊(duì)
