關於前端監控的思考

前端監控究竟是在監控什麼

基於數據驅動的作事原則，咱們須要統計線上項目中，用戶的行爲和使用狀況，從而更加貼近用戶，爲咱們的決策提供相應的數據支持，更好地迭代升級咱們的產品，創造用戶價值。
既然如此，研發同窗以及業務方對前端監控的訴求應該有：

1. 主動監控，並提供告警功能
2. 性能數據的採集，並提供慢會話的日誌分析
3. 錯誤，異常數據的採集
4. 能重現用戶行爲

而目前，對於咱們來講，須要作的前端監控包括： 異常監控，指標監控，埋點監控

異常監控

因爲前端代碼的執行環境很是複雜，很難保證在不一樣的環境下不出現問題，並且有些問題每每是由於瀏覽器或者操做的緣由，難以復現，因此咱們須要收集異常數據，方便開發定位問題。

指標監控

什麼是指標呢，我理解的應該是衡量咱們項目工程化能力的數據。好比咱們會記錄FCP做爲咱們的白屏時間，LCP做爲首屏時間，以及做業提交的失敗率等等。

埋點監控

這個主要是與業務相關，好比咱們會須要記錄咱們投放的營銷頁面的轉化率，用戶進入咱們的頁面以後，點擊了什麼按鈕，將頁面滾動到了什麼位置，等等。用於還原用戶行爲的信息記錄，爲業務方提供業務調整的方向和依據。

對於一個成熟的前端體系而言，一個靠譜的前端數據採集，上報，處理，監控報警平臺也是很是有必要的。

咱們須要收集哪些數據

根據上面說到的三個監控方向，咱們須要的監控數據以下：

錯誤數據

• Ajax/Fetch錯誤
• Promise錯誤
• window.onerror錯誤
• 靜態資源加載錯誤
• 自定義錯誤

指標數據

指標數據包括，性能數據(首屏時間，白屏時間，頁面是否卡頓，頁面加載全部資源的時間)，以及自定義的指標數據(視頻播放卡頓狀況，做業提交失敗率)

通用性能指標數據

前端相關的性能指標繁多，核心指標的設計咱們主要參考google提出的以用戶爲中心的原則來設計。

其主要根據視覺反饋來制定具體的性能指標，下面以打開一個web頁面爲例：

• 是否已發生？用戶感知到服務已有響應，相似傳統意義的白屏時間，fp/fcp
• 是否有用？重要內容是否渲染完畢？FMP ，比較接近首屏時間
• 是否可用？用戶能夠與頁面進行交互，也就是頁面的可交互時間， TTI
• 是否使人愉快？使用流暢 且無卡頓等，能夠檢查longtasks

除了以上幾項性能數據，其餘的如dns查詢時間等性能，主要做爲附加數據，僅在慢日誌時自動採集。

通用性能指標的採集，在實現方案上須要保持對業務較低的侵入性。

FP/FCP

FP(first paint): 首次繪製時間，能夠理解爲瀏覽器首個像素的繪製時間
FCP(first contentfull): 首次內容繪製，能夠理解爲首個可見元素的繪製時間，包含文本、圖片、canvas等。

從用戶的感知來說，fp時間接近白屏時間，fcp主要受index.html dom結構以及loading等影響。故咱們主要以fp爲參考指標。fp/fcp的採集，能夠直接使用paint timing api來採集，從測試數據來看，沒法是 spa仍是非spa頁面，fp都比較接近白屏時間。

FMP

FMP(first meaningful paint): 首次有效繪製，也就是頁面的核心元素渲染完成的時間點，不一樣的網站，核心元素的定位不同。

FMP 目前來看並無標準的API支持，google lighthouse中採集的fmp的準確率僅爲70%左右。可是能夠看到主流的前端監控，基本都將FMP做爲一項重要的性能指標。咱們能夠根據自身的業務特色，作關鍵的特徵提取，而後調整權重算法，達到較爲接近真實數據的指標。

TTI

TTI(Time-to-interactive): 用戶可交互時間，這個階段瀏覽器已完成渲染工做，並可影響用戶輸入的時間。

對於重交互的頁面，較爲關注 可交互時間，好比咱們的scratch3，對於重展現的頁面，對可交互時間的關注較弱，好比dm單

TTI指標的採集，google官方提供polyfill方法，可參考使用。

用戶行爲數據

咱們須要記錄用戶從進入頁面，點擊事件，滾動事件，離開頁面等操做

其餘數據

用戶瀏覽器信息 ,用戶硬件設備信息等等

對於以上數據，前端監控SDK是默認收集部分數據，也提供對應的接口，供項目調用上報到數據平臺。

總體架構設計

捕獲數據

目前主流的監控工具庫有sentry,badjs.saiji等等，通過充分調研後，認爲sentry可以匹配咱們的監控需求，可是因爲sentry並不能徹底知足咱們的監控需求，因此咱們對其進行了擴展。
實現捕獲數據的基本原理以下：

• Ajax/Fetch錯誤

一般是在http中使用中間件來處理，經過代理原生的XHR對象，以及原型方法和Fetch方法，來實現對http請求調用的攔截

• Promise錯誤

一般是經過監聽 unhandledrejection 來捕獲Promise被reject可是沒有catch的異常，並獲得關於異常的信息

• window.onerror錯誤

捕獲全局異常，不管異步仍是同步錯誤，onerror都能捕獲到運行時錯誤

• 靜態資源加載錯誤

一般是經過 window.addEventListener('error', function(event) { ... })來捕獲

• 性能數據

經過Performance API獲取頁面性能

• 用戶行爲

記錄用戶從進入頁面，點擊事件，滾動事件，離開頁面等操做

• 自定義數據

項目根據自身狀況，調用相應接口，上報到數據平臺

上報數據

• 避免頻繁上報，即經過延時，且事件知足或者數量量達到上限以後，將這段時間的全部數據合併上報
• 避免數據丟失，即講數據存儲到本地，優先使用indexDB,並降級使用localstorage，確保數據能離線存儲
• 避免流量浪費，因爲上報的數據包含大量的信息，如用戶操做，異常信息等等，經過上報前的數據壓縮，能極大地提升寬帶利用率

Node server中間層

• 與數據平臺節藕，數據平臺只須要關心數據的展現便可
• 上報的數據須要再次加工處理，好比經過前端上報的新鮮度時間，計算出實際的事件發生時間

大數據平臺

經過該平臺咱們能夠很直接地瞭解項目的各方面數據，以幫助咱們做出決策

總結

目前監控系統已經普遍應用在團隊的各個項目中，對了解項目性能，項目運行狀況，管理項目等提供了很大的幫助，也方便團隊作技術決策。