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

背景

每一個(gè)前端項(xiàng)目上線后都會(huì)在出現(xiàn)線上問(wèn)題，不論是PC項(xiàng)目還是移動(dòng)端項(xiàng)目，在后端服務(wù)中，可以通過(guò)錯(cuò)誤或業(yè)務(wù)日志來(lái)記錄錯(cuò)誤的情況，這些數(shù)據(jù)可以幫助開(kāi)發(fā)者快速定位系統(tǒng)的狀態(tài)，追查bug，了解錯(cuò)誤異常的基本情況。但是在前端開(kāi)發(fā)的領(lǐng)域內(nèi)，成型的日志監(jiān)控系統(tǒng)比較少見(jiàn)，尤其是在小程序端。

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

每當(dāng)小程序出現(xiàn)卡頓的情況，用戶都會(huì)下意識(shí)的考慮是自身手機(jī)的問(wèn)題，但是在使用別的小程序卻不存在這種問(wèn)題，就會(huì)導(dǎo)致用戶退出不再使用。因?yàn)樾〕绦虻奶攸c(diǎn)，獲取用戶的成本很低，同樣用戶放棄使用的成本也很低，那么既然用戶體驗(yàn)很差，所以用戶很大概率會(huì)直接退出，并且從此不再使用。

如上圖所示，微信在小程序后臺(tái)也有做錯(cuò)誤監(jiān)控，但是監(jiān)控手段沒(méi)法將錯(cuò)誤原因細(xì)分。比如以下幾點(diǎn)：
?  網(wǎng)絡(luò)請(qǐng)求錯(cuò)誤統(tǒng)計(jì)，但無(wú)法快速定位到服務(wù)端；

?  有JS錯(cuò)誤統(tǒng) 計(jì)，但無(wú)法快速定位錯(cuò)誤堆棧；

?  無(wú)頁(yè)面維度監(jiān)控，無(wú)法知道用戶打開(kāi)頁(yè)面的體驗(yàn)；

?  無(wú)地域運(yùn)營(yíng)商監(jiān)控，無(wú)法知道不同地域運(yùn)營(yíng)商下的小程序性能；

?  頁(yè)面退出率高，無(wú)法知道是否是性能導(dǎo)致的；

?  關(guān)于promise或async/await異步方法中報(bào)錯(cuò)信息的沒(méi)有監(jiān)控。

設(shè)計(jì)方案

1. 架構(gòu)設(shè)計(jì)

在參考了市面上諸多的監(jiān)控系統(tǒng)，并結(jié)合原始前端監(jiān)控的結(jié)構(gòu)，總結(jié)一下：

1）SDK編寫(xiě)，主要是暴力埋點(diǎn)，錯(cuò)誤攔截，代理監(jiān)控，上報(bào)策略，API設(shè)計(jì)，日志接口以及數(shù)據(jù)存儲(chǔ)；

2）上報(bào)的日志實(shí)現(xiàn)實(shí)時(shí)查詢；

3）監(jiān)控日志可視化管理后臺(tái)的開(kāi)發(fā)。

以上3點(diǎn)是基本，后期可以再加入場(chǎng)景重現(xiàn)，多平臺(tái)管理，郵件報(bào)警等成熟的功能

2. 流程設(shè)計(jì)

用戶在使用小程序的整體生命周期內(nèi)，sdk扮演一個(gè)類似行車記錄儀的角色，用戶在點(diǎn)擊使用產(chǎn)品時(shí)觸發(fā)到項(xiàng)目?jī)?nèi)部的錯(cuò)誤，SDK接收到這個(gè)信息，然后將這個(gè)錯(cuò)誤觸發(fā)的時(shí)間點(diǎn)以及作為開(kāi)發(fā)正想要收集的錯(cuò)誤信息在本地先做一個(gè)簡(jiǎn)單的整理， 作為主體上報(bào)至后臺(tái)服務(wù)端，服務(wù)端接收數(shù)據(jù)并根據(jù)預(yù)先定好的規(guī)則保存進(jìn)入數(shù)據(jù)庫(kù)當(dāng)我們打開(kāi)后臺(tái)管理系統(tǒng)的時(shí)候會(huì)將這些數(shù)據(jù)以項(xiàng)目分組的形式，再做錯(cuò)誤分組，做一個(gè)可視化的展示。當(dāng)某些錯(cuò)誤到達(dá)上限閾值的時(shí)候會(huì)向項(xiàng)目的參與人發(fā)送報(bào)警郵件。

3. SDK設(shè)計(jì)

如何定位小程序前端線上問(wèn)題，是一個(gè)比較復(fù)雜的問(wèn)題，因?yàn)樗赡茉谟脩羰褂眠^(guò)程中的一系列操作之后發(fā)生，錯(cuò)誤的原因有很多，可能源于不同機(jī)型，不同環(huán)境版本，網(wǎng)絡(luò)接口，請(qǐng)求環(huán)境或者復(fù)雜的操作等。

尤其是這樣四個(gè)W的問(wèn)題：誰(shuí)在什么環(huán)境下做了什么導(dǎo)致什么錯(cuò)誤？

接下來(lái)，我先從這個(gè)角度開(kāi)始設(shè)計(jì)小程序監(jiān)控系統(tǒng)。

WHO did WHAT and make WHICHerror in WHICH environment？

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

基礎(chǔ)用戶信息，當(dāng)監(jiān)聽(tīng)到用戶在引入sdk時(shí)有配置開(kāi)關(guān)，那就可以在小程序項(xiàng)目啟動(dòng)的到時(shí)候執(zhí)行微信原生方法，獲取用戶信息。其中網(wǎng)絡(luò)狀態(tài)中的IP是需要在上報(bào)錯(cuò)誤的時(shí)候服務(wù)端獲取，此外openid和unionid因?yàn)椴煌男〕绦蛟讷@取到之后一般保存在全局globalData或本地storage緩存中。

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

小程序在整個(gè)使用的生命周期里面出現(xiàn)的 各種直觀的錯(cuò)誤情況，我從用戶可視角度分為五種，對(duì)于開(kāi)發(fā)者和運(yùn)營(yíng)者來(lái)說(shuō)，錯(cuò)誤等級(jí)和優(yōu)先級(jí)都是一致的。

正常情況下，一般用戶使用時(shí)出現(xiàn)這些問(wèn)題的時(shí)候都會(huì)首先想到的是自身手機(jī)出現(xiàn)問(wèn)題，可是如果其他小程序可以正常使用，或者使用流程沒(méi)有問(wèn)題的話，用戶的流失率就會(huì)增加。所以，當(dāng)頁(yè)面出現(xiàn)這些問(wèn)題的時(shí)候都可以認(rèn)定他發(fā)生了錯(cuò)誤。

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

這里要獲取的是錯(cuò)誤的分類，三種類型的錯(cuò)誤：

1）http請(qǐng)求錯(cuò)誤

a、請(qǐng)求返回的statusCode不是200時(shí)

b、request的fail回調(diào)函數(shù)被觸發(fā)時(shí)

當(dāng)發(fā)生以上事件時(shí)，存儲(chǔ)兩部分日志，一個(gè)是請(qǐng)求的堆棧信息，一個(gè)是事件請(qǐng)求的全部信息，包括請(qǐng)求頭部，請(qǐng)求方式，請(qǐng)求參數(shù)，請(qǐng)求地址等。

2）js請(qǐng)求錯(cuò)誤

JavaScript異常監(jiān)控的方法采用暴力埋點(diǎn)的方式，但是由于它會(huì)造成污染代碼的后果，所以在api使用的時(shí)候會(huì)提供開(kāi)關(guān)的形式來(lái)謹(jǐn)慎選擇。默認(rèn)采用劫持函數(shù)的形式。

在默認(rèn)app.js中監(jiān)聽(tīng)onLaunch、onShow、onHide、onError生命周期函數(shù)，其中在onLaunch中執(zhí)行獲取用戶基礎(chǔ)信息，當(dāng)監(jiān)控到有執(zhí)行onError是就記錄一次報(bào)錯(cuò)信息。

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

3）資源上傳下載錯(cuò)誤

小程序不能直接分享到朋友圈，我們一般采用的方法是將小程序碼繪制成canvas圖片，然后保存到手機(jī)相冊(cè)，再以圖片的形式來(lái)分享朋友圈。上傳圖片或canvas上的元素時(shí)，采用wx.uploadFile方法來(lái)上傳，然后繪制對(duì)應(yīng)文件的tempFilePaths緩存，這時(shí)我們可以監(jiān)控wx.uploadFile的fail回調(diào)函數(shù)。當(dāng)我們要把繪制好的圖片保存到相冊(cè)時(shí)，使用wx.downloadFile方法，這里也是監(jiān)控這個(gè)方法的fail回調(diào)函數(shù)。

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

此外，為了更好地復(fù)現(xiàn)用戶的操作流程，當(dāng)用戶再點(diǎn)擊頁(yè)面按鈕或者打開(kāi)頁(yè)面的時(shí)候，sdk還會(huì)收集保存頁(yè)面的堆棧信息和執(zhí)行方法的堆棧信息，這樣在可視化后臺(tái)就可以直接觀察出用戶的使用流程。

每一條錯(cuò)誤信息在上報(bào)的時(shí)候都會(huì)存儲(chǔ)這些類型的數(shù)據(jù)，當(dāng)收集到信息的時(shí)候就會(huì)在sdk中對(duì)錯(cuò)誤進(jìn)行分類，根據(jù)捕獲的錯(cuò)誤關(guān)鍵字來(lái)區(qū)分錯(cuò)誤的類型和等級(jí)。在上報(bào)的同時(shí)增加每條錯(cuò)誤信息的標(biāo)識(shí)和分組。

4. 上報(bào)方式

異常錯(cuò)誤上報(bào)方式采用接口請(qǐng)求的方式，將具體數(shù)據(jù)收集到后向服務(wù)端發(fā)送，無(wú)需關(guān)注是否發(fā)送成功，但是，考慮到在大型應(yīng)用中，日志量比較大，我采取抽樣，合并，過(guò)濾三個(gè)方法減少日志的輸出。

再使用api的時(shí)候可以配置當(dāng)前日志達(dá)到多少條的時(shí)候進(jìn)行上報(bào)，默認(rèn)值為3條，同時(shí)可以配置上報(bào)接口是異步還是同步，init的時(shí)候配置reportType的方式是sync（同步）/async（異步），默認(rèn)為sync。

在初始化sdk的時(shí)候可以新增錯(cuò)誤類型，當(dāng)發(fā)現(xiàn)監(jiān)控到的錯(cuò)誤是屬于配置好的信息，那就選擇不上報(bào)。

上報(bào)錯(cuò)誤消息，但是這里需要再做一個(gè)操作，那就是監(jiān)控的是非上報(bào)接口的https請(qǐng)求。如果監(jiān)控系統(tǒng)的服務(wù)出現(xiàn)什么問(wèn)題導(dǎo)致這個(gè)上報(bào)接口失敗，那就說(shuō)明這個(gè)借口已經(jīng)出錯(cuò)。如果同步監(jiān)聽(tīng)的話，就會(huì)導(dǎo)致陷入死循環(huán)，不停地監(jiān)控不停的上報(bào)。所以需要將這個(gè)接口或者域名排除出去。

5. 后臺(tái)可視化系統(tǒng)

當(dāng)服務(wù)端得到前端上報(bào)的信息之后，經(jīng)過(guò)數(shù)據(jù)分析和處理，需要前端可視化的展示數(shù)據(jù)分析后的結(jié)果。

這個(gè)后臺(tái)其實(shí)是一般的工具系統(tǒng)，包括用戶管理、權(quán)限管理、錯(cuò)誤聚合以及展示錯(cuò)誤詳情。具體展示整個(gè)應(yīng)用的日志和單個(gè)用戶的單個(gè)錯(cuò)誤。

1）整個(gè)應(yīng)用：

· 固定時(shí)間段內(nèi)的發(fā)生的錯(cuò)誤總數(shù)，錯(cuò)誤占比，可視化曲線走勢(shì)圖

· 相同錯(cuò)誤的分組集合信息

· 每一項(xiàng)分組的錯(cuò)誤優(yōu)先級(jí)，開(kāi)發(fā)人員的分配，可操作功能

· 根據(jù)sdk版本，錯(cuò)誤分類篩選

2）單個(gè)用戶

· 用戶基本訪問(wèn)頁(yè)面堆棧信息，執(zhí)行方法堆棧信息，接口請(qǐng)求堆棧信息

· 每條錯(cuò)誤的基本信息，錯(cuò)誤位置，詳情，錯(cuò)誤時(shí)間點(diǎn)

· 用戶基礎(chǔ)信息，手機(jī)版本，使用基本場(chǎng)景

總結(jié)

前端的錯(cuò)誤監(jiān)控是一個(gè)任重而道遠(yuǎn)的任務(wù)，它的存在對(duì)任何前端開(kāi)發(fā)都起一個(gè)相當(dāng)重要的作用。我們監(jiān)控系統(tǒng)是針對(duì)微信小程序的原生前端代碼做異常監(jiān)控，會(huì)逐步針對(duì)百度，支付寶，頭條小程序做兼容，做到一套SDK監(jiān)控全平臺(tái)。

因?yàn)樾〕绦虻奶厥庑?，它不同于傳統(tǒng)的web前端監(jiān)控，對(duì)于部分能有效的體現(xiàn)錯(cuò)誤詳情的方式還不夠友好，我們將通過(guò)soursemap等方式來(lái)變相模擬。同時(shí)也會(huì)對(duì)promise或async/await等做兼容監(jiān)控，對(duì)上報(bào)方式作出更優(yōu)化的處理。

作者簡(jiǎn)介：

趙炳琦  58同城ABG高級(jí)前端開(kāi)發(fā)工程師 負(fù)責(zé)二手車小程序相關(guān)開(kāi)發(fā)