[[243715]]

 前端監(jiān)控包括行為監(jiān)控、 異常監(jiān)控 、性能監(jiān)控等，本文主要討論異常監(jiān)控。對(duì)于前端而言，和后端處于同一個(gè)監(jiān)控系統(tǒng)中，前端有自己的監(jiān)控方案，后端也有自己等監(jiān)控方案，但兩者并不分離，因?yàn)橐粋€(gè)用戶在操作應(yīng)用過程中如果出現(xiàn)異常，有可能是前端引起，也有可能是后端引起，需要有一個(gè)機(jī)制，將前后端串聯(lián)起來，使監(jiān)控本身統(tǒng)一于監(jiān)控系統(tǒng)。因此，即使只討論前端異常監(jiān)控，其實(shí)也不能嚴(yán)格區(qū)分前后端界限，而要根據(jù)實(shí)際系統(tǒng)的設(shè)計(jì)，在最終的報(bào)表中體現(xiàn)出監(jiān)控對(duì)開發(fā)和業(yè)務(wù)的幫助。

一般而言，一個(gè)監(jiān)控系統(tǒng)，大致可以分為四個(gè)階段：日志采集、日志存儲(chǔ)、統(tǒng)計(jì)與分析、報(bào)告和警告。

采集階段：收集異常日志，先在本地做一定的處理，采取一定的方案上報(bào)到服務(wù)器。

存儲(chǔ)階段：后端接收前端上報(bào)的異常日志，經(jīng)過一定處理，按照一定的存儲(chǔ)方案存儲(chǔ)。

分析階段：分為機(jī)器自動(dòng)分析和人工分析。機(jī)器自動(dòng)分析，通過預(yù)設(shè)的條件和算法，對(duì)存儲(chǔ)的日志信息進(jìn)行統(tǒng)計(jì)和篩選，發(fā)現(xiàn)問題，觸發(fā)報(bào)警。人工分析，通過提供一個(gè)可視化的數(shù)據(jù)面板，讓系統(tǒng)用戶可以看到具體的日志數(shù)據(jù)，根據(jù)信息，發(fā)現(xiàn)異常問題根源。

報(bào)警階段：分為告警和預(yù)警。告警按照一定的級(jí)別自動(dòng)報(bào)警，通過設(shè)定的渠道，按照一定的觸發(fā)規(guī)則進(jìn)行。預(yù)警則在異常發(fā)生前，提前預(yù)判，給出警告。

1 前端異常

前端異常是指在用戶使用Web應(yīng)用時(shí)無法快速得到符合預(yù)期結(jié)果的情況，不同的異常帶來的后果程度不同，輕則引起用戶使用不悅，重則導(dǎo)致產(chǎn)品無法使用，使用戶喪失對(duì)產(chǎn)品的認(rèn)可。

1.1 前端異常分類

根據(jù)異常代碼的后果的程度，對(duì)前端異常的表現(xiàn)分為如下幾類

a. 出錯(cuò)

界面呈現(xiàn)的內(nèi)容與用戶預(yù)期的內(nèi)容不符，例如點(diǎn)擊進(jìn)入非目標(biāo)界面，數(shù)據(jù)不準(zhǔn)確，出現(xiàn)的錯(cuò)誤提示不可理解，界面錯(cuò)位，提交后跳轉(zhuǎn)到錯(cuò)誤界面等情況。這類異常出現(xiàn)時(shí)，雖然產(chǎn)品本身功能還能正常使用，但用戶無法達(dá)成自己目標(biāo)。

b. 呆滯

界面出現(xiàn)操作后沒有反應(yīng)的現(xiàn)象，例如點(diǎn)擊按鈕無法提交，提示成功后無法繼續(xù)操作。這類異常出現(xiàn)時(shí)，產(chǎn)品已經(jīng)存在界面級(jí)局部不可用現(xiàn)象。

c. 損壞

界面出現(xiàn)無法實(shí)現(xiàn)操作目的的現(xiàn)象，例如點(diǎn)擊無法進(jìn)入目標(biāo)界面，點(diǎn)擊無法查看詳情內(nèi)容等。這類異常出現(xiàn)時(shí)，應(yīng)用部分功能無法被正常使用。

d. 假死

界面出現(xiàn)卡頓，無法對(duì)任何功能進(jìn)行使用的現(xiàn)象。例如用戶無法登陸導(dǎo)致無法使用應(yīng)用內(nèi)功能，由于某個(gè)遮罩層阻擋且不可關(guān)閉導(dǎo)致無法進(jìn)行任何后續(xù)操作。這類異常出現(xiàn)時(shí)，用戶很可能殺死應(yīng)用。

e. 崩潰

應(yīng)用出現(xiàn)經(jīng)常性自動(dòng)退出或無法操作的現(xiàn)象。例如間歇性crash，網(wǎng)頁無法正常加載或加載后無法進(jìn)行任何操作。這類異常持續(xù)出現(xiàn)，將直接導(dǎo)致用戶流失，影響產(chǎn)品生命力。

1.2 異常錯(cuò)誤原因分類

前端產(chǎn)生異常的原因主要分5類：

原因	案例	頻率
邏輯錯(cuò)誤	1)    業(yè)務(wù)邏輯判斷條件錯(cuò)誤  2)    事件綁定順序錯(cuò)誤  3)    調(diào)用棧時(shí)序錯(cuò)誤  4)    錯(cuò)誤的操作js對(duì)象	經(jīng)常
數(shù)據(jù)類型錯(cuò)誤	1)    將null視作對(duì)象讀取property  2)    將undefined視作數(shù)組進(jìn)行遍歷  3)    將字符串形式的數(shù)字直接用于加運(yùn)算  4)    函數(shù)參數(shù)未傳	經(jīng)常
語法句法錯(cuò)誤		較少
網(wǎng)絡(luò)錯(cuò)誤	1)    慢  2)    服務(wù)端未返回?cái)?shù)據(jù)但仍200，前端按正常進(jìn)行數(shù)據(jù)遍歷  3)    提交數(shù)據(jù)時(shí)網(wǎng)絡(luò)中斷  4)    服務(wù)端500錯(cuò)誤時(shí)前端未做任何錯(cuò)誤處理	偶爾
系統(tǒng)錯(cuò)誤	1)    內(nèi)存不夠用  2)    磁盤塞滿  3)    殼不支持API  4)    不兼容	較少

2 異常采集

2.1 采集內(nèi)容

當(dāng)異常出現(xiàn)的時(shí)候，我們需要知道異常的具體信息，根據(jù)異常的具體信息來決定采用什么樣的解決方案。在采集異常信息時(shí)，可以遵循4W原則：

WHO   did WHAT  and  get WHICH exception   in WHICH environment ?

a. 用戶信息

出現(xiàn)異常時(shí)該用戶的信息，例如該用戶在當(dāng)前時(shí)刻的狀態(tài)、權(quán)限等，以及需要區(qū)分用戶可多終端登錄時(shí)，異常對(duì)應(yīng)的是哪一個(gè)終端。

b. 行為信息

用戶進(jìn)行什么操作時(shí)產(chǎn)生了異常：所在的界面路徑；執(zhí)行了什么操作；操作時(shí)使用了哪些數(shù)據(jù)；當(dāng)時(shí)的API吐了什么數(shù)據(jù)給客戶端；如果是提交操作，提交了什么數(shù)據(jù)；上一個(gè)路徑；上一個(gè)行為日志記錄ID等。

c. 異常信息

產(chǎn)生異常的代碼信息：用戶操作的DOM元素節(jié)點(diǎn)；異常級(jí)別；異常類型；異常描述；代碼stack信息等。

d. 環(huán)境信息

網(wǎng)絡(luò)環(huán)境；設(shè)備型號(hào)和標(biāo)識(shí)碼；操作系統(tǒng)版本；客戶端版本；API接口版本等。

字段	類型	解釋
requestId	String	一個(gè)界面產(chǎn)生一個(gè)requestId
traceId	String	一個(gè)階段產(chǎn)生一個(gè)traceId，用于追蹤和一個(gè)異常相關(guān)的所有日志記錄
hash	String	這條log的唯一標(biāo)識(shí)碼，相當(dāng)于logId，但它是根據(jù)當(dāng)前日志記錄的具體內(nèi)容而生成的
time	Number	當(dāng)前日志產(chǎn)生的時(shí)間（保存時(shí)刻）
userId	String
userStatus	Number	當(dāng)時(shí)，用戶狀態(tài)信息（是否可用/禁用）
userRoles	Array	當(dāng)時(shí)，前用戶的角色列表
userGroups	Array	當(dāng)時(shí)，用戶當(dāng)前所在組，組別權(quán)限可能影響結(jié)果
userLicenses	Array	當(dāng)時(shí)，許可證，可能過期
path	String	所在路徑，URL
action	String	進(jìn)行了什么操作
referer	String	上一個(gè)路徑，來源URL
prevAction	String	上一個(gè)操作
data	Object	當(dāng)前界面的state、data
dataSources	Array<Object>	上游api給了什么數(shù)據(jù)
dataSend	Object	提交了什么數(shù)據(jù)
targetElement	HTMLElement	用戶操作的DOM元素
targetDOMPath	Array<HTMLElement>	該DOM元素的節(jié)點(diǎn)路徑
targetCSS	Object	該元素的自定義樣式表
targetAttrs	Object	該元素當(dāng)前的屬性及值
errorType	String	錯(cuò)誤類型
errorLevel	String	異常級(jí)別
errorStack	String	錯(cuò)誤stack信息
errorFilename	String	出錯(cuò)文件
errorLineNo	Number	出錯(cuò)行
errorColNo	Number	出錯(cuò)列位置
errorMessage	String	錯(cuò)誤描述（開發(fā)者定義）
errorTimeStamp	Number	時(shí)間戳
eventType	String	事件類型
pageX	Number	事件x軸坐標(biāo)
pageY	Number	事件y軸坐標(biāo)
screenX	Number	事件x軸坐標(biāo)
screenY	Number	事件y軸坐標(biāo)
pageW	Number	頁面寬度
pageH	Number	頁面高度
screenW	Number	屏幕寬度
screenH	Number	屏幕高度
eventKey	String	觸發(fā)事件的鍵
network	String	網(wǎng)絡(luò)環(huán)境描述
userAgent	String	客戶端描述
device	String	設(shè)備描述
system	String	操作系統(tǒng)描述
appVersion	String	應(yīng)用版本
apiVersion	String	接口版本

這是一份非常龐大的日志字段表，它幾乎囊括了一個(gè)異常發(fā)生時(shí)，能夠?qū)Ξ惓Ｖ茉猸h(huán)境進(jìn)行詳細(xì)描述的所有信息。不同情況下，這些字段并不一定都會(huì)收集，由于我們會(huì)采用文檔數(shù)據(jù)庫存儲(chǔ)日志，因此，并不影響它的實(shí)際存儲(chǔ)結(jié)果。

2.2 異常捕獲

前端捕獲異常分為全局捕獲和單點(diǎn)捕獲。全局捕獲代碼集中，易于管理；單點(diǎn)捕獲作為補(bǔ)充，對(duì)某些特殊情況進(jìn)行捕獲，但分散，不利于管理。

a、全局捕獲

通過全局的接口，將捕獲代碼集中寫在一個(gè)地方，可以利用的接口有：

• window.addEventListener(‘error’) / window.addEventListener(“unhandledrejection”) / document.addEventListener(‘click’) 等
• 框架級(jí)別的全局監(jiān)聽，例如aixos中使用interceptor進(jìn)行攔截，vue、react都有自己的錯(cuò)誤采集接口
• 通過對(duì)全局函數(shù)進(jìn)行封裝包裹，實(shí)現(xiàn)在在調(diào)用該函數(shù)時(shí)自動(dòng)捕獲異常
• 對(duì)實(shí)例方法重寫（Patch），在原有功能基礎(chǔ)上包裹一層，例如對(duì)console.error進(jìn)行重寫，在使用方法不變的情況下也可以異常捕獲

b、單點(diǎn)捕獲

在業(yè)務(wù)代碼中對(duì)單個(gè)代碼塊進(jìn)行包裹，或在邏輯流程中打點(diǎn)，實(shí)現(xiàn)有針對(duì)性的異常捕獲：

• try…catch
• 專門寫一個(gè)函數(shù)來收集異常信息，在異常發(fā)生時(shí)，調(diào)用該函數(shù)
• 專門寫一個(gè)函數(shù)來包裹其他函數(shù)，得到一個(gè)新函數(shù)，該新函數(shù)運(yùn)行結(jié)果和原函數(shù)一模一樣，只是在發(fā)生異常時(shí)可以捕獲異常

2.3 跨域腳本異常

由于瀏覽器安全策略限制，跨域腳本報(bào)錯(cuò)時(shí)，無法直接獲取錯(cuò)誤的詳細(xì)信息，只能得到一個(gè)Script Error。例如，我們會(huì)引入第三方依賴，或者將自己的腳本放在CDN時(shí)。

解決Script Error的方法：

方案一：

• 將js內(nèi)聯(lián)到HTML中
• 將js文件與HTML放在同域下

方案二：

1. 為頁面上script標(biāo)簽添加crossorigin屬性
2. 被引入腳本所在服務(wù)端響應(yīng)頭中，增加 Access-Control-Allow-Origin 來支持跨域資源共享

2.4 異常錄制

對(duì)于一個(gè)異常，僅僅擁有該異常的信息還不足以完全抓住問題的本質(zhì)，因?yàn)楫惓０l(fā)生的位置，并不一定是異常根源所在的位置。我們需要對(duì)異常現(xiàn)場(chǎng)進(jìn)行還原，才能復(fù)原問題全貌，甚至避免類似問題在其他界面中發(fā)生。這里需要引進(jìn)一個(gè)概念，就是“異常錄制”。錄制通過“時(shí)間”“空間”兩個(gè)維度記錄異常發(fā)生前到發(fā)生的整個(gè)過程，對(duì)于找到異常根源更有幫助。

上圖表示，當(dāng)異常發(fā)生時(shí)，異常的根源可能離我們很遠(yuǎn)，我們需要回到異常發(fā)生的現(xiàn)場(chǎng)，找到異常根源。就像現(xiàn)實(shí)生活中破案一樣，如果有監(jiān)控?cái)z影機(jī)對(duì)案發(fā)過程的錄影，對(duì)破案來說更加容易。如果僅僅關(guān)注異常本身，要找到異常的根源，需要憑借運(yùn)氣，但有了異常錄制的幫助，找到根源就更加容易。

所謂的“異常錄制”，實(shí)際上就是通過技術(shù)手段，收集用戶的操作過程，對(duì)用戶的每一個(gè)操作都進(jìn)行記錄，在發(fā)生異常時(shí)，把一定時(shí)間區(qū)間內(nèi)的記錄重新運(yùn)行，形成影像進(jìn)行播放，讓調(diào)試者無需向用戶詢問，就能看到用戶當(dāng)時(shí)的操作過程。

上圖是來自阿里的一套異常錄制還原方案示意圖，用戶在界面上的操作產(chǎn)生的events和mutation被產(chǎn)品收集起來，上傳到服務(wù)器，經(jīng)過隊(duì)列處理按順序存放到數(shù)據(jù)庫中。當(dāng)需要進(jìn)行異常重現(xiàn)的時(shí)候，將這些記錄從數(shù)據(jù)庫中取出，采用一定的技術(shù)方案，順序播放這些記錄，即可實(shí)現(xiàn)異常還原。

2.5 異常級(jí)別

一般而言，我們會(huì)將收集信息的級(jí)別分為info，warn，error等，并在此基礎(chǔ)上進(jìn)行擴(kuò)展。

當(dāng)我們監(jiān)控到異常發(fā)生時(shí)，可以將該異常劃分到“重要——緊急”模型中分為A、B、C、D四個(gè)等級(jí)。有些異常，雖然發(fā)生了，但是并不影響用戶的正常使用，用戶其實(shí)并沒有感知到，雖然理論上應(yīng)該修復(fù)，但是實(shí)際上相對(duì)于其他異常而言，可以放在后面進(jìn)行處理。

下文會(huì)討論告警策略，一般而言，越靠近右上角的異常會(huì)越快通知，保證相關(guān)人員能最快接收到信息，并進(jìn)行處理。A級(jí)異常需要快速響應(yīng)，甚至需要相關(guān)負(fù)責(zé)人知悉。

在收集異常階段，可根據(jù)第一節(jié)劃分的異常后果來判斷異常的嚴(yán)重程度，在發(fā)生異常時(shí)選擇對(duì)應(yīng)的上報(bào)方案進(jìn)行上報(bào)。

3 整理與上報(bào)方案

前文已經(jīng)提到，除了異常報(bào)錯(cuò)信息本身，我們還需要記錄用戶操作日志，以實(shí)現(xiàn)場(chǎng)景復(fù)原。這就涉及到上報(bào)的量和頻率問題。如果任何日志都立即上報(bào)，這無異于自造的DDOS攻擊。因此，我們需要合理的上報(bào)方案。下文會(huì)介紹4種上報(bào)方案，但實(shí)際我們不會(huì)僅限于其中一種，而是經(jīng)常同時(shí)使用，對(duì)不同級(jí)別的日志選擇不同的上報(bào)方案。

3.1 前端存儲(chǔ)日志

我們前面提到，我們并不單單采集異常本身日志，而且還會(huì)采集與異常相關(guān)的用戶行為日志。單純一條異常日志并不能幫助我們快速定位問題根源，找到解決方案。但如果要收集用戶的行為日志，又要采取一定的技巧，而不能用戶每一個(gè)操作后，就立即將該行為日志傳到服務(wù)器，對(duì)于具有大量用戶同時(shí)在線的應(yīng)用，如果用戶一操作就立即上傳日志，無異于對(duì)日志服務(wù)器進(jìn)行DDOS攻擊。因此，我們先將這些日志存儲(chǔ)在用戶客戶端本地，達(dá)到一定條件之后，再同時(shí)打包上傳一組日志。

那么，如何進(jìn)行前端日志存儲(chǔ)呢？我們不可能直接將這些日志用一個(gè)變量保存起來，這樣會(huì)擠爆內(nèi)存，而且一旦用戶進(jìn)行刷新操作，這些日志就丟失了，因此，我們自然而然想到前端數(shù)據(jù)持久化方案。

目前，可用的持久化方案可選項(xiàng)也比較多了，主要有：Cookie、localStorage、sessionStorage、IndexedDB、webSQL 、FileSystem 等等。那么該如何選擇呢？我們通過一個(gè)表來進(jìn)行對(duì)比：

存儲(chǔ)方式	cookie	localStorage	sessionStorage	IndexedDB	webSQL	FileSystem
類型		key-value	key-value	NoSQL	SQL
數(shù)據(jù)格式	string	string	string	object
容量	4k	5M	5M	500M	60M
進(jìn)程	同步	同步	同步	異步	異步
檢索		key	key	key, index	field
性能		讀快寫慢		讀慢寫快

綜合之后，IndexedDB是最好的選擇，它具有容量大、異步的優(yōu)勢(shì)，異步的特性保證它不會(huì)對(duì)界面的渲染產(chǎn)生阻塞。而且IndexedDB是分庫的，每個(gè)庫又分store，還能按照索引進(jìn)行查詢，具有完整的數(shù)據(jù)庫管理思維，比localStorage更適合做結(jié)構(gòu)化數(shù)據(jù)管理。但是它有一個(gè)缺點(diǎn)，就是api非常復(fù)雜，不像localStorage那么簡(jiǎn)單直接。針對(duì)這一點(diǎn)，我們可以使用hello-indexeddb這個(gè)工具，它用Promise對(duì)復(fù)雜api進(jìn)行來封裝，簡(jiǎn)化操作，使IndexedDB的使用也能做到localStorage一樣便捷。另外，IndexedDB是被廣泛支持的HTML5標(biāo)準(zhǔn)，兼容大部分瀏覽器，因此不用擔(dān)心它的發(fā)展前景。

接下來，我們究竟應(yīng)該怎么合理使用IndexedDB，保證我們前端存儲(chǔ)的合理性呢？

上圖展示了前端存儲(chǔ)日志的流程和數(shù)據(jù)庫布局。當(dāng)一個(gè)事件、變動(dòng)、異常被捕獲之后，形成一條初始日志，被立即放入暫存區(qū)（indexedDB的一個(gè)store），之后主程序就結(jié)束了收集過程，后續(xù)的事只在webworker中發(fā)生。在一個(gè)webworker中，一個(gè)循環(huán)任務(wù)不斷從暫存區(qū)中取出日志，對(duì)日志進(jìn)行分類，將分類結(jié)果存儲(chǔ)到索引區(qū)中，并對(duì)日志記錄的信息進(jìn)行豐富，將最終將會(huì)上報(bào)到服務(wù)端的日志記錄轉(zhuǎn)存到歸檔區(qū)。而當(dāng)一條日志在歸檔區(qū)中存在的時(shí)間超過一定天數(shù)之后，它就已經(jīng)沒有價(jià)值了，但是為了防止特殊情況，它被轉(zhuǎn)存到回收區(qū)，再經(jīng)歷一段時(shí)間后，就會(huì)被從回收區(qū)中清除。

3.2 前端整理日志

上文講到，在一個(gè)webworker中對(duì)日志進(jìn)行整理后存到索引區(qū)和歸檔區(qū)，那么這個(gè)整理過程是怎樣的呢？

由于我們下文要講的上報(bào)，是按照索引進(jìn)行的，因此，我們?cè)谇岸说娜罩菊砉ぷ鳎饕褪歉鶕?jù)日志特征，整理出不同的索引。我們?cè)谑占罩緯r(shí)，會(huì)給每一條日志打上一個(gè)type，以此進(jìn)行分類，并創(chuàng)建索引，同時(shí)通過object-hashcode計(jì)算每個(gè)log對(duì)象的hash值，作為這個(gè)log的唯一標(biāo)志。

• 將所有日志記錄按時(shí)序存放在歸檔區(qū)，并將新入庫的日志加入索引
• BatchIndexes：批量上報(bào)索引（包含性能等其他日志），可一次批量上報(bào)100條
• MomentIndexes：即時(shí)上報(bào)索引，一次全部上報(bào)
• FeedbackIndexes：用戶反饋索引，一次上報(bào)一條
• BlockIndexes：區(qū)塊上報(bào)索引，按異常/錯(cuò)誤（traceId，requestId）分塊，一次上報(bào)一塊
• 上報(bào)完成后，被上報(bào)過的日志對(duì)應(yīng)的索引刪除
• 3天以上日志進(jìn)入回收區(qū)
• 7天以上的日志從回收區(qū)清除

rquestId：同時(shí)追蹤前后端日志。由于后端也會(huì)記錄自己的日志，因此，在前端請(qǐng)求api的時(shí)候，默認(rèn)帶上requestId，后端記錄的日志就可以和前端日志對(duì)應(yīng)起來。

traceId：追蹤一個(gè)異常發(fā)生前后的相關(guān)日志。當(dāng)應(yīng)用啟動(dòng)時(shí)，創(chuàng)建一個(gè)traceId，直到一個(gè)異常發(fā)生時(shí)，刷新traceId。把一個(gè)traceId相關(guān)的requestId收集起來，把這些requestId相關(guān)的日志組合起來，就是最終這個(gè)異常相關(guān)的所有日志，用來對(duì)異常進(jìn)行復(fù)盤。

上圖舉例展示了如何利用traceId和requestId找出和一個(gè)異常相關(guān)的所有日志。在上圖中，hash4是一條異常日志，我們找到hash4對(duì)應(yīng)的traceId為traceId2，在日志列表中，有兩條記錄具有該traceId，但是hash3這條記錄并不是一個(gè)動(dòng)作的開始，因?yàn)閔ash3對(duì)應(yīng)的requestId為reqId2，而reqId2開始于hash2，因此，我們實(shí)際上要把hash2也加入到該異常發(fā)生的整個(gè)復(fù)盤備選記錄中。總結(jié)起來就是，我們要找出同一個(gè)traceId對(duì)應(yīng)的所有requestId對(duì)應(yīng)的日志記錄，雖然有點(diǎn)繞，但稍理解就可以明白其中的道理。

我們把這些和一個(gè)異常相關(guān)的所有日志集合起來，稱為一個(gè)block，再利用日志的hash集合，得出這個(gè)block的hash，并在索引區(qū)中建立索引，等待上報(bào)。

3.3 上報(bào)日志

上報(bào)日志也在webworker中進(jìn)行，為了和整理區(qū)分，可以分兩個(gè)worker。上報(bào)的流程大致為：在每一個(gè)循環(huán)中，從索引區(qū)取出對(duì)應(yīng)條數(shù)的索引，通過索引中的hash，到歸檔區(qū)取出完整的日志記錄，再上傳到服務(wù)器。

按照上報(bào)的頻率（重要緊急度）可將上報(bào)分為四種：

a. 即時(shí)上報(bào)

收集到日志后，立即觸發(fā)上報(bào)函數(shù)。僅用于A類異常。而且由于受到網(wǎng)絡(luò)不確定因素影響，A類日志上報(bào)需要有一個(gè)確認(rèn)機(jī)制，只有確認(rèn)服務(wù)端已經(jīng)成功接收到該上報(bào)信息之后，才算完成。否則需要有一個(gè)循環(huán)機(jī)制，確保上報(bào)成功。

b. 批量上報(bào)

將收集到的日志存儲(chǔ)在本地，當(dāng)收集到一定數(shù)量之后再打包一次性上報(bào)，或者按照一定的頻率（時(shí)間間隔）打包上傳。這相當(dāng)于把多次合并為一次上報(bào)，以降低對(duì)服務(wù)器的壓力。

c. 區(qū)塊上報(bào)

將一次異常的場(chǎng)景打包為一個(gè)區(qū)塊后進(jìn)行上報(bào)。它和批量上報(bào)不同，批量上報(bào)保證了日志的完整性，全面性，但會(huì)有無用信息。而區(qū)塊上報(bào)則是針對(duì)異常本身的，確保單個(gè)異常相關(guān)的日志被全部上報(bào)。

d. 用戶主動(dòng)提交

在界面上提供一個(gè)按鈕，用戶主動(dòng)反饋bug。這有利于加強(qiáng)與用戶的互動(dòng)。

或者當(dāng)異常發(fā)生時(shí)，雖然對(duì)用戶沒有任何影響，但是應(yīng)用監(jiān)控到了，彈出一個(gè)提示框，讓用戶選擇是否愿意上傳日志。這種方案適合涉及用戶隱私數(shù)據(jù)時(shí)。

	即時(shí)上報(bào)	批量上報(bào)	區(qū)塊上報(bào)	用戶反饋
時(shí)效	立即	定時(shí)	稍延時(shí)	延時(shí)
條數(shù)	一次全部上報(bào)	一次100條	單次上報(bào)相關(guān)條目	一次1條
容量	小	中	–	–
緊急	緊急重要	不緊急	不緊急但重要	不緊急

即時(shí)上報(bào)雖然叫即時(shí)，但是其實(shí)也是通過類似隊(duì)列的循環(huán)任務(wù)去完成的，它主要是盡快把一些重要的異常提交給監(jiān)控系統(tǒng)，好讓運(yùn)維人員發(fā)現(xiàn)問題，因此，它對(duì)應(yīng)的緊急程度比較高。

批量上報(bào)和區(qū)塊上報(bào)的區(qū)別：批量上報(bào)是一次上報(bào)一定條數(shù)，比如每2分鐘上報(bào)1000條，直到上報(bào)完成。而區(qū)塊上報(bào)是在異常發(fā)生之后，馬上收集和異常相關(guān)的所有日志，查詢出哪些日志已經(jīng)由批量上報(bào)上報(bào)過了，剔除掉，把其他相關(guān)日志上傳，和異常相關(guān)的這些日志相對(duì)而言更重要一些，它們可以幫助盡快復(fù)原異常現(xiàn)場(chǎng)，找出發(fā)生異常的根源。

用戶提交的反饋信息，則可以慢悠悠上報(bào)上去。

為了確保上報(bào)是成功的，在上報(bào)時(shí)需要有一個(gè)確認(rèn)機(jī)制，由于在服務(wù)端接收到上報(bào)日志之后，并不會(huì)立即存入數(shù)據(jù)庫，而是放到一個(gè)隊(duì)列中，因此，前后端在確保日志確實(shí)已經(jīng)記錄進(jìn)數(shù)據(jù)庫這一點(diǎn)上需要再做一些處理。

上圖展示了上報(bào)的一個(gè)大致流程，在上報(bào)時(shí)，先通過hash查詢，讓客戶端知道準(zhǔn)備要上報(bào)的日志集合中，是否存在已經(jīng)被服務(wù)端保存好的日志，如果已經(jīng)存在，就將這些日志去除，避免重復(fù)上報(bào)，浪費(fèi)流量。

3.4 壓縮上報(bào)數(shù)據(jù)

一次性上傳批量數(shù)據(jù)時(shí)，必然遇到數(shù)據(jù)量大，浪費(fèi)流量，或者傳輸慢等情況，網(wǎng)絡(luò)不好的狀態(tài)下，可能導(dǎo)致上報(bào)失敗。因此，在上報(bào)之前進(jìn)行數(shù)據(jù)壓縮也是一種方案。

對(duì)于合并上報(bào)這種情況，一次的數(shù)據(jù)量可能要十幾k，對(duì)于日 pv 大的站點(diǎn)來說，產(chǎn)生的流量還是很可觀的。所以有必要對(duì)數(shù)據(jù)進(jìn)行壓縮上報(bào)。lz-string是一個(gè)非常優(yōu)秀的字符串壓縮類庫，兼容性好，代碼量少，壓縮比高，壓縮時(shí)間短，壓縮率達(dá)到驚人的60%。但它基于LZ78壓縮，如果后端不支持解壓，可選擇gzip壓縮，一般而言后端會(huì)默認(rèn)預(yù)裝gzip，因此，選擇gzip壓縮數(shù)據(jù)也可以，工具包pako中自帶了gzip壓縮，可以嘗試使用。

4 日志接收與存儲(chǔ)

4.1 接入層與消息隊(duì)列

一般通過提供獨(dú)立的日志服務(wù)器接收客戶端日志，接收過程中，要對(duì)客戶端日志內(nèi)容的合法性、安全性等進(jìn)行甄別，防止被人攻擊。而且由于日志提交一般都比較頻繁，多客戶端同時(shí)并發(fā)的情況也常見。通過消息隊(duì)列將日志信息逐一處理后寫入到數(shù)據(jù)庫進(jìn)行保存也是比較常用的方案。

上圖為騰訊BetterJS的架構(gòu)圖，其中“接入層”和“推送中心”就是這里提到的接入層和消息隊(duì)列。BetterJS將整個(gè)前端監(jiān)控的各個(gè)模塊進(jìn)行拆分，推送中心承擔(dān)了將日志推送到存儲(chǔ)中心進(jìn)行存儲(chǔ)和推送給其他系統(tǒng)（例如告警系統(tǒng)）的角色，但我們可以把接收日志階段的隊(duì)列獨(dú)立出來看，在接入層和存儲(chǔ)層之間做一個(gè)過渡。

4.2 日志存儲(chǔ)系統(tǒng)

存儲(chǔ)日志是一個(gè)臟活累活，但是不得不做。對(duì)于小應(yīng)用，單庫單表加優(yōu)化就可以應(yīng)付。一個(gè)成規(guī)模的應(yīng)用，如果要提供更標(biāo)準(zhǔn)高效的日志監(jiān)控服務(wù)，常常需要在日志存儲(chǔ)架構(gòu)上下一些功夫。目前業(yè)界已經(jīng)有比較完備的日志存儲(chǔ)方案，主要有：Hbase系，Dremel系，Lucene系等。總體而言，日志存儲(chǔ)系統(tǒng)主要面對(duì)的問題是數(shù)據(jù)量大，數(shù)據(jù)結(jié)構(gòu)不規(guī)律，寫入并發(fā)高，查詢需求大等。一般一套日志存儲(chǔ)系統(tǒng)，要解決上面這些問題，就要解決寫入的緩沖，存儲(chǔ)介質(zhì)按日志時(shí)間選擇，為方便快速讀取而設(shè)計(jì)合理的索引系統(tǒng)等等。

由于日志存儲(chǔ)系統(tǒng)方案比較成熟，這里就不再做更多討論。

4.3 搜索

日志的最終目的是要使用，由于一般日志的體量都非常大，因此，要在龐大的數(shù)據(jù)中找到需要的日志記錄，需要依賴比較好的搜索引擎。Splunk是一套成熟的日志存儲(chǔ)系統(tǒng)，但它是付費(fèi)使用的。按照Splunk的框架，Elk是Splunk的開源實(shí)現(xiàn)，Elk是ElasticSearch、Logstash、Kibana的結(jié)合，ES基于Lucene的存儲(chǔ)、索引的搜索引擎；logstash是提供輸入輸出及轉(zhuǎn)化處理插件的日志標(biāo)準(zhǔn)化管道；Kibana提供可視化和查詢統(tǒng)計(jì)的用戶界面。

5 日志統(tǒng)計(jì)與分析

一個(gè)完善的日志統(tǒng)計(jì)分析工具需要提供各方面方便的面板，以可視化的方式給日志管理員和開發(fā)者反饋信息。

5.1 用戶緯度

同一個(gè)用戶的不同請(qǐng)求實(shí)際上會(huì)形成不同的story線，因此，針對(duì)用戶的一系列操作設(shè)計(jì)唯一的request id是有必要的。同一個(gè)用戶在不同終端進(jìn)行操作時(shí)，也能進(jìn)行區(qū)分。用戶在進(jìn)行某個(gè)操作時(shí)的狀態(tài)、權(quán)限等信息，也需要在日志系統(tǒng)中予以反應(yīng)。

5.2 時(shí)間維度

一個(gè)異常是怎么發(fā)生的，需要將異常操作的前后story線串聯(lián)起來觀察。它不單單涉及一個(gè)用戶的一次操作，甚至不限于某一個(gè)頁面，而是一連串事件的最終結(jié)果。

5.3 性能維度

應(yīng)用運(yùn)行過程中的性能情況，例如，界面加載時(shí)間，api請(qǐng)求時(shí)長(zhǎng)統(tǒng)計(jì)，單元計(jì)算的消耗，用戶呆滯時(shí)間。

5.4 運(yùn)行環(huán)境維度

應(yīng)用及服務(wù)所運(yùn)行的環(huán)境情況，例如應(yīng)用所在的網(wǎng)絡(luò)環(huán)境，操作系統(tǒng)，設(shè)備硬件信息等，服務(wù)器cpu、內(nèi)存狀況，網(wǎng)絡(luò)、寬帶使用情況等。

5.4 細(xì)粒度代碼追蹤

異常的代碼stack信息，定位到發(fā)生異常的代碼位置和異常堆棧。

5.6 場(chǎng)景回溯

通過將異常相關(guān)的用戶日志連接起來，以動(dòng)態(tài)的效果輸出發(fā)生異常的過程。

6 監(jiān)控與通知

對(duì)異常進(jìn)行統(tǒng)計(jì)和分析只是基礎(chǔ)，而在發(fā)現(xiàn)異常時(shí)可以推送和告警，甚至做到自動(dòng)處理，才是一個(gè)異常監(jiān)控系統(tǒng)應(yīng)該具備的能力。

6.1 自定義觸發(fā)條件的告警

a. 監(jiān)控實(shí)現(xiàn)

當(dāng)日志信息進(jìn)入接入層時(shí)，就可以觸發(fā)監(jiān)控邏輯。當(dāng)日志信息中存在較為高級(jí)別的異常時(shí)，也可以立即出發(fā)告警。告警消息隊(duì)列和日志入庫隊(duì)列可以分開來管理，實(shí)現(xiàn)并行。

對(duì)入庫日志信息進(jìn)行統(tǒng)計(jì)，對(duì)異常信息進(jìn)行告警。對(duì)監(jiān)控異常進(jìn)行響應(yīng)。所謂監(jiān)控異常，是指：有規(guī)律的異常一般而言都比較讓人放心，比較麻煩的是突然之間的異常。例如在某一時(shí)段突然頻繁接收到D級(jí)異常，雖然D級(jí)異常是不緊急一般重要，但是當(dāng)監(jiān)控本身發(fā)生異常時(shí)，就要提高警惕。

b. 自定義觸發(fā)條件

除了系統(tǒng)開發(fā)時(shí)配置的默認(rèn)告警條件，還應(yīng)該提供給日志管理員可配置的自定義觸發(fā)條件。

• 日志內(nèi)含有什么內(nèi)容時(shí)
• 日志統(tǒng)計(jì)達(dá)到什么度、量時(shí)
• 向符合什么條件的用戶告警

6.2 推送渠道

可選擇的途徑有很多，例如郵件、短信、微信、電話。

6.3 推送頻率

針對(duì)不同級(jí)別的告警，推送的頻率也可以進(jìn)行設(shè)定。低風(fēng)險(xiǎn)告警可以以報(bào)告的形式一天推送一次，高風(fēng)險(xiǎn)告警10分鐘循環(huán)推送，直到處理人手動(dòng)關(guān)閉告警開關(guān)。

6.4 自動(dòng)報(bào)表

對(duì)于日志統(tǒng)計(jì)信息的推送，可以做到自動(dòng)生成日?qǐng)?bào)、周報(bào)、月報(bào)、年報(bào)并郵件發(fā)送給相關(guān)群組。

6.5 自動(dòng)產(chǎn)生bug工單

當(dāng)異常發(fā)生時(shí)，系統(tǒng)可以調(diào)用工單系統(tǒng)API實(shí)現(xiàn)自動(dòng)生成bug單，工單關(guān)閉后反饋給監(jiān)控系統(tǒng)，形成對(duì)異常處理的追蹤信息進(jìn)行記錄，在報(bào)告中予以展示。

7 修復(fù)異常

7.1 sourcemap

前端代碼大部分情況都是經(jīng)過壓縮后發(fā)布的，上報(bào)的stack信息需要還原為源碼信息，才能快速定位源碼進(jìn)行修改。

發(fā)布時(shí)，只部署js腳本到服務(wù)器上，將sourcemap文件上傳到監(jiān)控系統(tǒng)，在監(jiān)控系統(tǒng)中展示stack信息時(shí)，利用sourcemap文件對(duì)stack信息進(jìn)行解碼，得到源碼中的具體信息。

但是這里有一個(gè)問題，就是sourcemap必須和正式環(huán)境的版本對(duì)應(yīng)，還必須和git中的某個(gè)commit節(jié)點(diǎn)對(duì)應(yīng)，這樣才能保證在查異常的時(shí)候可以正確利用stack信息，找到出問題所在版本的代碼。這些可以通過建立CI任務(wù)，在集成化部署中增加一個(gè)部署流程，以實(shí)現(xiàn)這一環(huán)節(jié)。

7.2 從告警到預(yù)警

預(yù)警的本質(zhì)是，預(yù)設(shè)可能出現(xiàn)異常的條件，當(dāng)觸發(fā)該條件時(shí)異常并沒有真實(shí)發(fā)生，因此，可以趕在異常發(fā)生之前對(duì)用戶行為進(jìn)行檢查，及時(shí)修復(fù)，避免異常或異常擴(kuò)大。

怎么做呢？其實(shí)就是一個(gè)統(tǒng)計(jì)聚類的過程。將歷史中發(fā)生異常的情況進(jìn)行統(tǒng)計(jì)，從時(shí)間、地域、用戶等不同維度加以統(tǒng)計(jì)，找出規(guī)律，并將這些規(guī)律通過算法自動(dòng)加入到預(yù)警條件中，當(dāng)下次觸發(fā)時(shí)，及時(shí)預(yù)警。

7.3 智能修復(fù)

自動(dòng)修復(fù)錯(cuò)誤。例如，前端要求接口返回?cái)?shù)值，但接口返回了數(shù)值型的字符串，那么可以有一種機(jī)制，監(jiān)控系統(tǒng)發(fā)送正確數(shù)據(jù)類型模型給后端，后端在返回?cái)?shù)據(jù)時(shí)，根據(jù)該模型控制每個(gè)字段的類型。

8 異常測(cè)試

8.1 主動(dòng)異常測(cè)試

撰寫異常用例，在自動(dòng)化測(cè)試系統(tǒng)中，加入異常測(cè)試用戶。在測(cè)試或運(yùn)行過程中，每發(fā)現(xiàn)一個(gè)異常，就將它加入到原有的異常用例列表中。

8.2 隨機(jī)異常測(cè)試

模擬真實(shí)環(huán)境，在模擬器中模擬真實(shí)用戶的隨機(jī)操作，利用自動(dòng)化腳本產(chǎn)生隨機(jī)操作動(dòng)作代碼，并執(zhí)行。

定義異常，例如彈出某個(gè)彈出框，包含特定內(nèi)容時(shí)，就是異常。將這些測(cè)試結(jié)果記錄下來，再聚類統(tǒng)計(jì)分析，對(duì)防御異常也很有幫助。

9 部署

9.1 多客戶端

一個(gè)用戶在不同終端上登錄，或者一個(gè)用戶在登錄前和登錄后的狀態(tài)。通過特定算法生成requestID，通過該requestId可以確定某個(gè)用戶在獨(dú)立客戶端上的一系列操作，根據(jù)日志時(shí)序，可以梳理出用戶產(chǎn)生異常的具體路徑。

9.2 集成便捷性

前端寫成包，全局引用即可完成大部分日志記錄、存儲(chǔ)和上報(bào)。在特殊邏輯里面，可以調(diào)用特定方法記錄日志。

后端與應(yīng)用本身的業(yè)務(wù)代碼解耦，可以做成獨(dú)立的服務(wù)，通過接口和第三方應(yīng)用交互。利用集成部署，可以將系統(tǒng)隨時(shí)進(jìn)行擴(kuò)容、移植等操作。

9.3 管理系統(tǒng)的可擴(kuò)展

整套系統(tǒng)可擴(kuò)展，不僅服務(wù)單應(yīng)用，可支持多個(gè)應(yīng)用同時(shí)運(yùn)行。同一個(gè)團(tuán)隊(duì)下的所有應(yīng)用都可以利用同一個(gè)平臺(tái)進(jìn)行管理。

9.4 日志系統(tǒng)權(quán)限

不同的人在訪問日志系統(tǒng)時(shí)權(quán)限不同，一個(gè)訪問者只能查看自己相關(guān)的應(yīng)用，有些統(tǒng)計(jì)數(shù)據(jù)如果比較敏感，可以單獨(dú)設(shè)置權(quán)限，敏感數(shù)據(jù)可脫敏。

10 其他

10.1 性能監(jiān)控

異常監(jiān)控主要針對(duì)代碼級(jí)別的報(bào)錯(cuò)，但也應(yīng)該關(guān)注性能異常。性能監(jiān)控主要包括：

• 運(yùn)行時(shí)性能：文件級(jí)、模塊級(jí)、函數(shù)級(jí)、算法級(jí)
• 網(wǎng)絡(luò)請(qǐng)求速率
• 系統(tǒng)性能

10.2 API Monitor

后端API對(duì)前端的影響也非常大，雖然前端代碼也控制邏輯，但是后端返回的數(shù)據(jù)是基礎(chǔ)，因此對(duì)API的監(jiān)控可以分為：

• 穩(wěn)定性監(jiān)控
• 數(shù)據(jù)格式和類型
• 報(bào)錯(cuò)監(jiān)控
• 數(shù)據(jù)準(zhǔn)確性監(jiān)控

10.3 數(shù)據(jù)脫敏

敏感數(shù)據(jù)不被日志系統(tǒng)采集。由于日志系統(tǒng)的保存是比較開放的，雖然里面的數(shù)據(jù)很重要，但是在存儲(chǔ)上大部分日志系統(tǒng)都不是保密級(jí)，因此，如果應(yīng)用涉及了敏感數(shù)據(jù)，最好做到：

• 獨(dú)立部署，不和其他應(yīng)用共享監(jiān)控系統(tǒng)
• 不采集具體數(shù)據(jù)，只采集用戶操作數(shù)據(jù)，在重現(xiàn)時(shí)，通過日志信息可以取出數(shù)據(jù)api結(jié)果來展示
• 日志加密，做到軟硬件層面的加密防護(hù)
• 必要時(shí)，可采集具體數(shù)據(jù)的ID用于調(diào)試，場(chǎng)景重現(xiàn)時(shí)，用mock數(shù)據(jù)替代，mock數(shù)據(jù)可由后端采用假的數(shù)據(jù)源生成
• 對(duì)敏感數(shù)據(jù)進(jìn)行混淆

結(jié)語

本文主要是對(duì)前端異常監(jiān)控的整體框架進(jìn)行了研究，沒有涉及到具體的技術(shù)實(shí)現(xiàn)，涉及前端部分和后臺(tái)部分以及與整個(gè)問題相關(guān)的一些知識(shí)點(diǎn)，主要關(guān)注前端部分，它和后端的監(jiān)控有重疊部分也有分支部分，需要在一個(gè)項(xiàng)目中不斷實(shí)踐，總結(jié)出項(xiàng)目本身的監(jiān)控需求和策略。