小程序錯誤異常監控方案

發表時間：2021-1-11

發布人：葵宇科技

浏覽次數：37

本文(wén)主要介紹了微信小程前端錯誤異常監控系統，用于捕獲收集線上小程序項目代碼在使用生命周期中(zhōng)出現的異常情況。

背景

每一個(gè)前端項目上線後都會在出現線上問(wèn)題，不論是PC項目還是移動(dòng)端項目，在後端服務中(zhōng)，可(kě)以通(tōng)過錯誤或業(yè)務日志來記錄錯誤的情況，這些數據可(kě)以幫助開發者快速定位系統的狀态，追查bug，了解錯誤異常的基本情況。但是在前端開發的領域内，成型的日志監控系統比較少(shǎo)見，尤其是在小程序端。

關(guān)于前端異常監控，網上有很多開源的項目，比如(rú)騰訊的badjs，淘寶的JSTracker，阿裡巴巴的fdSafe系統，支付寶的sai.js，國外的sentry異常捕獲平台，到目前為止，已經有很多的解決方案在很多年前被提出并且實現了，但是他們的方案并不是完全适用于每一個(gè)項目的開發者，比如(rú)國内的fundebug，關(guān)注了所有的Error收集場景，但是他們解決的問(wèn)題其實都是接下(xià)來要講到的一些通(tōng)用問(wèn)題，如(rú)果針對到具體項目，還是看業(yè)務方如(rú)何選擇。

每當小程序出現卡頓的情況，用戶都會下(xià)意識的考慮是自身手機的問(wèn)題，但是在使用别的小程序卻不存在這種問(wèn)題，就會導緻用戶退出不再使用。因為小程序的特點，獲取用戶的成本很低，同樣用戶放棄使用的成本也很低，那麼既然用戶體驗很差，所以用戶很大概率會直接退出，并且從此不再使用。

如(rú)上圖所示，微信在小程序後台也有做錯誤監控，但是監控手段沒法将錯誤原因細分。比如(rú)以下(xià)幾點：
? 網絡請求錯誤統計，但無法快速定位到服務端；

? 有JS錯誤統計，但無法快速定位錯誤堆棧；

? 無頁面維度監控，無法知道用戶打開頁面的體驗；

? 無地域運營商(shāng)監控，無法知道不同地域運營商(shāng)下(xià)的小程序性能；

? 頁面退出率高，無法知道是否是性能導緻的；

? 關(guān)于promise或async/await異步方法中(zhōng)報錯信息的沒有監控。

設計方案

1. 架構設計

在參考了市面上諸多的監控系統，并結合原始前端監控的結構，總結一下(xià)：

1）SDK編寫，主要是暴力埋點，錯誤攔截，代理監控，上報策略，API設計，日志接口以及數據存儲；

2）上報的日志實現實時查詢；

3）監控日志可(kě)視化管理後台的開發。

以上3點是基本，後期可(kě)以再加入場景重現，多平台管理，郵件報警等成熟的功能

2. 流程設計

用戶在使用小程序的整體生命周期内，sdk扮演一個(gè)類似行車(chē)記錄儀的角色，用戶在點擊使用産品時觸發到項目内部的錯誤，SDK接收到這個(gè)信息，然後将這個(gè)錯誤觸發的時間點以及作為開發正想要收集的錯誤信息在本地先做一個(gè)簡單的整理，作為主體上報至後台服務端，服務端接收數據并根據預先定好的規則保存進入數據庫當我們打開後台管理系統的時候會将這些數據以項目分組的形式，再做錯誤分組，做一個(gè)可(kě)視化的展示。當某些錯誤到達上限阈值的時候會向項目的參與人發送報警郵件。

3. SDK設計

如(rú)何定位小程序前端線上問(wèn)題，是一個(gè)比較複雜的問(wèn)題，因為它可(kě)能在用戶使用過程中(zhōng)的一系列操作之後發生，錯誤的原因有很多，可(kě)能源于不同機型，不同環境版本，網絡接口，請求環境或者複雜的操作等。

尤其是這樣四個(gè)W的問(wèn)題：誰在什麼環境下(xià)做了什麼導緻什麼錯誤？

接下(xià)來，我先從這個(gè)角度開始設計小程序監控系統。

WHO did WHAT and make WHICHerror in WHICH environment？

（1）第一個(gè)W——WHO

基礎用戶信息，當監聽到用戶在引入sdk時有配置開關(guān)，那就可(kě)以在小程序項目啟動(dòng)的到時候執行微信原生方法，獲取用戶信息。其中(zhōng)網絡狀态中(zhōng)的IP是需要在上報錯誤的時候服務端獲取，此外openid和(hé)unionid因為不同的小程序在獲取到之後一般保存在全局globalData或本地storage緩存中(zhōng)。

（2）第二個(gè)W——DO WHAT

小程序在整個(gè)使用的生命周期裡面出現的各種直觀的錯誤情況，我從用戶可(kě)視角度分為五種，對于開發者和(hé)運營者來說，錯誤等級和(hé)優先級都是一緻的。

正常情況下(xià)，一般用戶使用時出現這些問(wèn)題的時候都會首先想到的是自身手機出現問(wèn)題，可(kě)是如(rú)果其他小程序可(kě)以正常使用，或者使用流程沒有問(wèn)題的話，用戶的流失率就會增加。所以，當頁面出現這些問(wèn)題的時候都可(kě)以認定他發生了錯誤。

（3）第三個(gè)W——WHICH ERROR

這裡要獲取的是錯誤的分類，三種類型的錯誤：

1）http請求錯誤

a、請求返回的statusCode不是200時

b、request的fail回調函數被觸發時

當發生以上事件時，存儲兩部分日志，一個(gè)是請求的堆棧信息，一個(gè)是事件請求的全部信息，包括請求頭部，請求方式，請求參數，請求地址等。

2）js請求錯誤

JavaScript異常監控的方法采用暴力埋點的方式，但是由于它會造成污染代碼的後果，所以在api使用的時候會提供開關(guān)的形式來謹慎選擇。默認采用劫持函數的形式。

在默認app.js中(zhōng)監聽onLaunch、onShow、onHide、onError生命周期函數，其中(zhōng)在onLaunch中(zhōng)執行獲取用戶基礎信息，當監控到有執行onError是就記錄一次報錯信息。

js的錯誤類型主要分為以下(xià)幾種：

3）資(zī)源上傳下(xià)載錯誤

小程序不能直接分享到朋友圈，我們一般采用的方法是将小程序碼繪制成canvas圖片，然後保存到手機相冊，再以圖片的形式來分享朋友圈。上傳圖片或canvas上的元素時，采用wx.uploadFile方法來上傳，然後繪制對應文(wén)件的tempFilePaths緩存，這時我們可(kě)以監控wx.uploadFile的fail回調函數。當我們要把繪制好的圖片保存到相冊時，使用wx.downloadFile方法，這裡也是監控這個(gè)方法的fail回調函數。

（4）第四個(gè)W——WHICH ENVIRONMENT

此外，為了更好地複現用戶的操作流程，當用戶再點擊頁面按鈕或者打開頁面的時候，sdk還會收集保存頁面的堆棧信息和(hé)執行方法的堆棧信息，這樣在可(kě)視化後台就可(kě)以直接觀察出用戶的使用流程。

每一條錯誤信息在上報的時候都會存儲這些類型的數據，當收集到信息的時候就會在sdk中(zhōng)對錯誤進行分類，根據捕獲的錯誤關(guān)鍵字來區分錯誤的類型和(hé)等級。在上報的同時增加每條錯誤信息的标識和(hé)分組。

4. 上報方式

異常錯誤上報方式采用接口請求的方式，将具體數據收集到後向服務端發送，無需關(guān)注是否發送成功，但是，考慮到在大型應用中(zhōng)，日志量比較大，我采取抽樣，合并，過濾三個(gè)方法減少(shǎo)日志的輸出。

再使用api的時候可(kě)以配置當前日志達到多少(shǎo)條的時候進行上報，默認值為3條，同時可(kě)以配置上報接口是異步還是同步，init的時候配置reportType的方式是sync（同步）/async（異步），默認為sync。

在初始化sdk的時候可(kě)以新增錯誤類型，當發現監控到的錯誤是屬于配置好的信息，那就選擇不上報。

上報錯誤消息，但是這裡需要再做一個(gè)操作，那就是監控的是非上報接口的https請求。如(rú)果監控系統的服務出現什麼問(wèn)題導緻這個(gè)上報接口失敗，那就說明這個(gè)借口已經出錯。如(rú)果同步監聽的話，就會導緻陷入死循環，不停地監控不停的上報。所以需要将這個(gè)接口或者域名排除出去。