作者 | 墨輝
點選檢視視訊
大家好，我是來自阿裡巴巴淘系技術部的墨輝。今天分享主題是《如何建設灰階跨端監控》。
監控，安全生産的第一戰線，線上問題的發現能力以及如何快速定位問題是監控的核心能力。前端跨端方案不斷在演進，覆寫了web、weex、小程式等多種跨端方案場景。今天的主題從背景介紹、技術方案、線上案例、總結 4個次元來介紹灰階跨端監控。
背景介紹
首先介紹下跨端的背景，打開一個H5或者pc的頁面，從傳統前端監控視角去看，我們一般隻會關注頁面運作過程的異常監控，比如 JSError、接口異常、性能等這些名額。
今天，我們業務運作在很多不同的跨端的方案，比如 weex、小程式、rn、flutter等。從跨端監控視角看，需要做到全鍊路的監控。比如容器啟動異常、頁面加載白屏、頁面執行過程導緻crash等問題的監控。
回到安全生産的背景，我們統計了淘系前端财年故障，我們發現線上問題 80% 是變更引起的以及故障平均修複時長超過了 300 分鐘，我們來分析下具體原因：
線上變更引起故障，大部分是沒有被監控發現，根據上圖分析下監控沒有被發現的原因。從趨勢圖看出，在10點左右有個釋出節點，日志有個小幅度的增長，增長過程沒有觸發報警，原因主要包含兩個：
- 大盤日志的增長并不明顯
- 缺少細分的次元來區分日志增長的來源
上面我們提到了，平均修複時間超過了300分鐘，一個完整的流程流程包含兩個階段
- 開發階段，從需求評審、需求開發以及測試驗證
- 釋出階段，開發完成之後，釋出過程會有個漸漸放量的過程，内部灰階 -> 外部灰階，最後完整上線
如果一個問題完整上線才發現，會帶來問題修複周期長和影響範圍廣的問題。要解決這些問題，需要在灰階釋出過程來提前發現問題。
灰階監控是要解決釋出過程的監控，核心要解決三個問題：
- 不同的跨端容器（weex、小程式等）怎麼建設灰階監控
- 灰階報警和普通報警的差異是什麼
- 灰階釋出過程的監控，如何幫助業務更好定位問題
技術方案
下面介紹下整體技術方案。
技術方案分為四個部分：
- 灰階釋出：釋出分為兩種，一種是類似小程式這種，打包成zip包釋出上線；一種是正常頁面釋出，靜态資源釋出到CDN
- 日志采集：頁面運作過程需要采集監控的名額，比如js執行報錯、接口異常等名額上報
- 資料處理：資料上報完成之後，需要對資料清洗和字段處理
- 灰階監控：基于處理後的資料結果，完成灰階監控的建設
上面提到，兩種釋出方式，首先看下靜态資源釋出，比如weex或者web這種場景，一般在cdn層做灰階控制。如果命中，通路的是灰階版本。未命中，通路的是線上版本。
ZIP打包一般分為兩種場景，具體如下：
- 小程式場景，打包成ZIP包釋出上線
- WEB離線場景，做資源加載的優化，會将靜态資源打包成離線ZIP包做釋出上線
對于ZIP還是非ZIP釋出場景，目前版本和線上版本需要從三個字段次元來區分：
- 版本号，用來确認目前日志是在哪個版本發生的
- 是否命中灰階，用來區分目前版本是不是灰階中的版本
- 目前環境，用來區分日志的來源環境
端外采集，一般是web場景，受限于浏覽器，需要通過全局變量的方式來擷取。可以在腳手架初始化過程注入到模闆并服務端渲染對變量指派，通過采集SDK讀取變量擷取灰階辨別資訊，具體內建方式如下：
<meta name="page-tag" content="env=spe,grey=true,release=0.0.1" /> 容器采集，通過擴充response header資訊來擷取。拉取資源的時候，可以直接讀取資源的response資訊來擷取灰階辨別資訊，具體內建方式如下：
grey: 'true'
env: 'spe'
release: '0.0.1'
date: 'Fri, 11 Dec 2020 13:12:04 GMT'
content-type: 'text/html; charset=utf-8'
..... 資料處理過程，主要包含對髒日志清洗、資料字段規範、資料字段解析、資料分類存儲等，具體如下：
- 擷取原始日志，不同的跨端容器日志統一上報到TT平台。TT平台是流式資料處理平台，通過在TT平台訂閱消息，拿到上報的原始日志
- 實時日志處理，基于Blink台完成，Blink是流式實時計算平台，主要是做日志清洗以及把日志轉成規範格式日志
- 資料存儲，将清洗後的日志存儲到SLS，基于SLS日志存儲服務，可以對日志進行實時查詢和分析
- 資料應用，基于node層，做實時日志查詢、輪詢報警等應用能力
安全生産背景分析發現小幅度日志增長，缺少細分的次元來區分日志增長的來源。現在日志包含了版本号、環境、是否命中灰階次元資訊，通過這些次元區分出新增錯誤日志和日志的增長比例，來打造灰階報警和灰階實時監控能力。
灰階報警是在node層啟動一個程序做輪詢任務，拉取頁面釋出清單資料，對比頁面的線上版本日志和灰階版本日志。基于新增日志和日志的增長比例的報警政策來觸發報警。
灰階實時監控目标是幫助業務更快和直覺的發現問題，需要将核心資料更直覺的透出在資料圖表上，核心名額資料包含：
- 灰階比例，灰階命中占整體流量的比例。通過線上的采集pv和灰階版本的采集pv來計算出灰階比例
- 詳細日志狀态，比如JSError名額，通過灰階版本的日志和線上的日志做相似度算法比較，可以對日志聚合分類，計算出新增的錯誤類型和錯誤增長比例
實時監控效果如上圖所示，通過兩部分來看這個圖表：
- 日志走勢，綠色的線可以區分出灰階命中占整體流量的比例，紅色和藍色的線可以區分灰階版本和線上版本日志總量的比例
- 日志分布，對日志做了兩種狀态辨別，新增日志狀态和日志增長的比例。通過日志的變化趨勢狀态，可以直覺的判斷灰階版本是否符合預期
線上案例
介紹一個具體案例，一次新需求疊代，流量灰階5%左右的時候，發現一個報錯日志增長了接近5倍，通過及時復原避免的線上一次故障。
總結
做下技術方案總結，灰階監控分為四個過程：
- 灰階釋出，對于WEB、小程式、WEEX等灰階釋出能力的覆寫
- 名額采集，浏覽器采集通過讀取模闆變量的方式，容器采集通過讀取response header資訊擷取灰階辨別
- 監控名額，覆寫全鍊路監控名額，日志上報過程中攜帶灰階版本資訊并轉成規範日志格式
- 灰階應用，通過灰階釋出的資訊次元做日志分析，來打造灰階報警和灰階實時監控能力
🔥第十五屆 D2 前端技術論壇 PPT 集合已放出，馬上擷取
關注「Alibaba F2E」
回複 「PPT」一鍵擷取大會完整PPT