|
在復(fù)雜的網(wǎng)絡(luò)環(huán)境和瀏覽器環(huán)境下,，自測、QA測試以及 Code Review 都是不夠的,，如果對頁面穩(wěn)定性和準(zhǔn)確性要求較高,，就必須有一套完善的代碼異常監(jiān)控體系，本文從前端代碼異常監(jiān)控的方法和問題著手,，盡量全面地闡述錯(cuò)誤日志收集各個(gè)階段中可能遇到的阻礙和處理方案,。 收集日志的方法 平時(shí)收集日志的手段，可以歸類為兩個(gè)方面,，一個(gè)是邏輯中的錯(cuò)誤判斷,，為主動(dòng)判斷；一個(gè)是利用語言給我們提供的捷徑,，暴力式獲取錯(cuò)誤信息,，如 try..catch 和 window.onerror。 1. 主動(dòng)判斷 我們在一些運(yùn)算之后,，得到一個(gè)期望的結(jié)果,，然而結(jié)果不是我們想要的  // test.jsfunction calc(){ // code... return val;}if(calc() !== 'someVal'){ Reporter.send({ position: 'test.js::calc' msg: 'calc error' });} 這種屬于邏輯錯(cuò)誤/狀態(tài)錯(cuò)誤的反饋，在接口 status 判斷中用的比較多,。 2. try..catch 捕獲 判斷一個(gè)代碼段中存在的錯(cuò)誤： try { init(); // code...} catch(e){ Reporter.send(format(e));} 以 init 為程序的入口,，代碼中所有同步執(zhí)行出現(xiàn)的錯(cuò)誤都會(huì)被捕獲，這種方式也可以很好的避免程序剛跑起來就掛,。 3. window.onerror 捕獲全局錯(cuò)誤： window.onerror = function() { var errInfo = format(arguments); Reporter.send(errInfo); return true;}; 在上面的函數(shù)中返回 return true,，錯(cuò)誤便不會(huì)暴露到控制臺(tái)中。下面是它的參數(shù)信息： /** * @param {String} errorMessage 錯(cuò)誤信息 * @param {String} scriptURI 出錯(cuò)的文件 * @param {Long} lineNumber 出錯(cuò)代碼的行號 * @param {Long} columnNumber 出錯(cuò)代碼的列號 * @param {Object} errorObj 錯(cuò)誤的詳細(xì)信息,，Anything */window.onerror = function(errorMessage, scriptURI, lineNumber,columnNumber,errorObj) { // code..} window.onerror 算是一種特別暴力的容錯(cuò)手段,，try..catch 也是如此，他們底層的實(shí)現(xiàn)就是利用 C/C++ 中的 goto 語句實(shí)現(xiàn),，一旦發(fā)現(xiàn)錯(cuò)誤,，不管目前的堆棧有多深,，不管代碼運(yùn)行到了何處,，直接跑到頂層或者 try..catch 捕獲的那一層，這種一腳踢開錯(cuò)誤的處理方式并不是很好。 收集日志存在的問題 收集日志的目的是為了及時(shí)發(fā)現(xiàn)問題,，最好日志能夠告訴我們,，錯(cuò)誤在哪里，更優(yōu)秀的做法是,，不僅告訴錯(cuò)誤在哪里,，還告訴我們，如何處理這個(gè)錯(cuò)誤,。終極目標(biāo)是,，發(fā)現(xiàn)錯(cuò)誤，自動(dòng)容錯(cuò),，這一步是最難的,。 1. 無具體報(bào)錯(cuò)信息，Script error. 先看下面的例子,，test.html script> window.onerror = function(){ console.log(arguments); };script>script src='http://barret/test.js'>script> test.js  // http://barret/test.jsfunction test(){ ver a = 1; return a+1;}test(); 我們期望收集到的日志是下面這樣具體的信息： 為了對資源進(jìn)行更好的配置和管理,，我們通常將靜態(tài)資源放到異域上 script> window.onerror = function(){ console.log(arguments); };script>script src='http://localhost/test.js'>script> 而拿到的結(jié)果卻是： 翻開 Chromium 的 WebCore 源碼，可以看到： 跨域情況下,，返回的結(jié)果是 Script error.,。 // http://trac./browser/branches/chromium/1453/Source/WebCore/dom/ScriptExecutionContext.cpp#L333String message = errorMessage;int line = lineNumber;String sourceName = sourceURL;// 已經(jīng)拿到了所有的錯(cuò)誤信息，但如果發(fā)現(xiàn)是非同源情況,，`sanitizeScriptError` 中復(fù)寫錯(cuò)誤信息sanitizeScriptError(message, line, sourceName, cachedScript); 舊版 的 WebCore 中只判斷了 securityOrigin()->canRequest(targetURL),，新版中還多了一個(gè) cachedScript 的判斷，可以看出瀏覽器對這方面的限制越來越嚴(yán)格,。 在本地測試了下： 可見在 file:// 協(xié)議下,，securityOrigin()->canRequest(targetURL) 也是 false。 為何Script error.? 簡單報(bào)錯(cuò)： Script error,，目的是避免數(shù)據(jù)泄露到不安全的域中,，一個(gè)簡單的例子： script src='bank.com/login.html'>script> 上面我們并沒有引入一個(gè) js 文件，而是一個(gè) html,，這個(gè) html 是銀行的登錄頁面,，如果你已經(jīng)登錄了 bank.com，那 login 頁面就會(huì)自動(dòng)跳轉(zhuǎn)到 Welcome xxx...,，如果未登錄則跳轉(zhuǎn)到 Please Login...,，那么 JS 報(bào)錯(cuò)也會(huì)是 Welcome xxx... is not defined，Please Login... is not defined,，通過這些信息可以判斷一個(gè)用戶是否登錄他的銀行賬號,，給 hacker 提供了十分便利的判斷渠道，這是相當(dāng)不安全的,。 crossOrigin參數(shù)跳過跨域限制 image 和 script 標(biāo)簽都有 crossorigin 參數(shù),，它的作用就是告訴瀏覽器,，我要加載一個(gè)外域的資源，并且我信任這個(gè)資源,。 script src='http://localhost/test.js' crossorigin>script> 然而,，卻報(bào)錯(cuò)了： 這是意料之中的錯(cuò)誤，跨域資源共享策略要求,，服務(wù)器也設(shè)置 Access-Control-Allow-Origin 的響應(yīng)頭： header('Access-Control-Allow-Origin: *'); 回頭看看我們 CDN 的資源,， Javascript/CSS/Image/Font/SWF 等這些靜態(tài)資源其實(shí)都已經(jīng)早早地加上了 CORS 響應(yīng)頭。 2. 壓縮代碼無法定位到錯(cuò)誤的具體位置 線上的代碼幾乎都是經(jīng)過打包壓縮的,，幾十上百的文件壓縮后打包成一個(gè),，而且只有一行。當(dāng)我們收到 a is not defined 的時(shí)候,，如果只在特定場景下才報(bào)錯(cuò),，我們根本無法定位到這個(gè)被壓縮的 a 是個(gè)什么東西，那么此時(shí)的錯(cuò)誤日志就是無效的,。 第一個(gè)想到的辦法是利用 sourceMap,，利用它可以定位到壓縮代碼某一點(diǎn)在未壓縮代碼的具體位置。下面是 sourceMap 引入的格式,，在代碼的最后一行加入： //# sourceMappingURL=index.js.map 以前使用的是 ‘//@’ 作為開頭,，現(xiàn)在使用 ‘//#’，然而對于錯(cuò)誤上報(bào),，這玩意兒沒啥用,。JS 不能拿到他真實(shí)的行數(shù)，只能通過 Chrome DevTools 這樣的工具輔助定位,，而且并不是每個(gè)線上資源都會(huì)添加 sourceMap 文件,。sourceMap 的用途目前還只能體現(xiàn)在開發(fā)階段。 當(dāng)然,，如果理解了 sourceMap 的 VLQ編碼和位置對應(yīng)關(guān)系,，也可以將拿到的日志進(jìn)行二次解析，映射到真實(shí)路徑位置,，這個(gè)成本比較高,，貌似暫時(shí)也沒人嘗試過。 那么,，有什么辦法,，可以定位錯(cuò)誤的具體位置，或者說有什么辦法可以縮小我們定位問題的難度呢,？ 可以這樣考慮：打包的時(shí)候,，在每兩個(gè)合并的文件之間加上 1000 個(gè)空行，最后上線的文件就會(huì)變成 (function(){var longCode.....})(); // file 1// 1000 個(gè)空行(function(){var longCode.....})(); // file 2// 1000 個(gè)空行(function(){var longCode.....})(); // file 3// 1000 個(gè)空行(function(){var longCode.....})(); // file 4var _fileConfig = ['file 1', 'file 2', 'file 3', 'file 4'] 如果報(bào)錯(cuò)在第 3001 行,， window.onerror = function(msg, url, line, col, error){ // line = 3001 var lineNum = line; console.log('錯(cuò)誤位置：' + _fileConfig[parseInt(lineNum / 1000) - 1]); // -> '錯(cuò)誤位置：file 3'}; 可以計(jì)算出,，錯(cuò)誤出現(xiàn)在第三個(gè)文件中,，范圍就縮小了很多。 3. error 事件的注冊 多次注冊 error 事件,，不會(huì)重復(fù)執(zhí)行多個(gè)回調(diào)： var fn = window.onerror = function() { console.log(arguments);};window.addEventListener('error', fn);window.addEventListener('error', fn); 觸發(fā)錯(cuò)誤之后，上面代碼的結(jié)果為： window.onerror 和 addEventListener 都執(zhí)行了,，并只執(zhí)行了一次,。 4. 收集日志的量 沒有必要將所有的錯(cuò)誤信息全部送到 Log 中，這個(gè)量太大了,。如果網(wǎng)頁 PV 有 1kw,，那么一個(gè)必現(xiàn)錯(cuò)誤發(fā)送的 log 信息將有 1kw 條，大約一個(gè) G 的日志,。我們可以給 Reporter 函數(shù)添加一個(gè)采樣率： function needReport (sampling){ // sampling: 0 - 1 return Math.random() sampling;}Reporter.send = function(errInfo, sampling) { if(needReport(sampling || 1)){ Reporter._send(errInfo); }}; 這個(gè)采樣率可以按需求來處理,，可以同上，使用一個(gè)隨機(jī)數(shù),，也可以使用 cookie 中的某個(gè)字段（如 nickname）的最后一個(gè)字母/數(shù)字來判定,，也可以將用戶的 nickname 進(jìn)行 hash 計(jì)算，再通過最后一位的字母/數(shù)字來判斷,，總之,，方法是很多的。 收集日志布點(diǎn)位置 為了更加精準(zhǔn)的拿到錯(cuò)誤信息,，有效地統(tǒng)計(jì)錯(cuò)誤日志,，我們應(yīng)該更多地采用主動(dòng)式埋點(diǎn)，比如在一個(gè)接口的請求中： // Module A Get Shops Data$.ajax({ url: URL, dataType: 'jsonp', success: function(ret) { if(ret.status === 'failed') { // 埋點(diǎn) 1 return Reporter.send({ category: 'WARN', msg: 'Module_A_GET_SHOPS_DATA_FAILED' }); } if(!ret.data || !ret.data.length) { // 埋點(diǎn) 2 return Reporter.send({ category: 'WARN', msg: 'Module_A_GET_SHOPS_DATA_EMPTY' }); } }, error: function() { // 埋點(diǎn) 3 Reporter.send({ category: 'ERROR', msg: 'Module_A_GET_SHOPS_DATA_ERROR' }); }}); 上面我們精準(zhǔn)地布下了三個(gè)點(diǎn),，描述十分清晰,，這三個(gè)點(diǎn)會(huì)對我們后續(xù)排查線上問題提供十分有利的信息。 關(guān)于 try..catch 的使用 對于 try..catch 的使用,，我的建議是：能不用,，盡量不要用。JS代碼都是自己寫出來的,，哪里會(huì)出現(xiàn)問題,，會(huì)出現(xiàn)什么問題，心中應(yīng)該都有個(gè)譜,，平時(shí)用到 try..catch 的一般只有兩個(gè)地方： // JSON 格式不對try{ JSON.parse(JSONString);}catch(e){}// 存在不可 decode 的字符try{ decodeComponentURI(string);}catch(e){} 類似這樣的錯(cuò)誤都是不太可控的,。可以在使用到 try..catch 的地方思考是否可以使用其他方式做兼容,。感謝 EtherDream 的補(bǔ)充,。 關(guān)于 window.onerror 的使用 可以嘗試如下代碼： // test.jsthrow new Error('SHOW ME');window.onerror = function(){ console.log(arguments); // 阻止在控制臺(tái)中打印錯(cuò)誤信息 return true;}; 上面的代碼直接報(bào)錯(cuò)了，沒有繼續(xù)往下執(zhí)行,。頁面中可能有好幾個(gè) script 標(biāo)簽,，但是 window.onerror 這個(gè)錯(cuò)誤監(jiān)聽一定要放到最前頭,！ 錯(cuò)誤的警報(bào)與提示 什么時(shí)候該警報(bào)？不能有錯(cuò)就報(bào),。上面也說了,，因?yàn)榫W(wǎng)絡(luò)環(huán)境和瀏覽器環(huán)境因素，復(fù)雜頁面我們允許千分之一的錯(cuò)誤率,。日志處理后的數(shù)據(jù)圖： 圖中有兩根線,，橙色線是今日的數(shù)據(jù)，淺藍(lán)色線是往日平均數(shù)據(jù),，每隔 10 分鐘產(chǎn)生一條記錄,，橫坐標(biāo)是 0-24 點(diǎn)的時(shí)間軸，縱坐標(biāo)是錯(cuò)誤量,?？梢院苊黠@的看出，在凌晨一兩點(diǎn)左右,，服務(wù)出現(xiàn)了異常,，錯(cuò)誤信息是平均值的十幾倍，那么這個(gè)時(shí)候就改報(bào)警了,。 報(bào)警的條件可以設(shè)置得嚴(yán)苛一點(diǎn),，因?yàn)檎`報(bào)是件很煩人的事情，短信,、郵件,、軟件等信息轟炸，有的時(shí)候還是大半夜,。那么,，一般滿足如下條件可以報(bào)警： 錯(cuò)誤超過閾值，比如 10分鐘最多允許 100 個(gè)錯(cuò)誤,，結(jié)果超過了 100 錯(cuò)誤超過平均值的 10 倍,，超過平均值就報(bào)警，這個(gè)邏輯顯然不正確,，但是超過了平均值的 10 倍,，基本可以認(rèn)定服務(wù)出問題了 在納入對比之前，要過濾同 IP 出現(xiàn)的錯(cuò)誤,，比如一個(gè)錯(cuò)誤出現(xiàn)在 for 循環(huán)或者 while 循環(huán)中,，再比如一個(gè)用戶在蹲點(diǎn)搶購，不停的刷新 友好的錯(cuò)誤提示 對比下面兩條日志,，catch 的錯(cuò)誤日志： Uncaught ReferenceError: vd is not defined 自定義的錯(cuò)誤日志： “生日模塊中獲取后端接口信息時(shí),，eval 解析出錯(cuò)，錯(cuò)誤內(nèi)容為：vd is not defined.” 該錯(cuò)誤在最近 10 分鐘內(nèi)出現(xiàn) 1000 次,，這個(gè)錯(cuò)誤往日的平均出錯(cuò)量是 50 次 / 10 分鐘 網(wǎng)絡(luò)錯(cuò)誤日志工作草案 W3C Web Performance工作組發(fā)布了網(wǎng)絡(luò)錯(cuò)誤日志工作草案,。該文檔定義了一個(gè)機(jī)制,，允許Web站點(diǎn)聲明一個(gè)網(wǎng)絡(luò)錯(cuò)誤匯報(bào)策略，瀏覽器等用戶代理可以利用這一機(jī)制,，匯報(bào)影響資源正確加載的網(wǎng)絡(luò)錯(cuò)誤,。該文檔還定義了一個(gè)錯(cuò)誤報(bào)告的標(biāo)準(zhǔn)格式及其在瀏覽器和Web服務(wù)器之間的傳輸機(jī)制。 詳細(xì)草案：http://www./TR/2015/WD-network-error-logging-20150305/ 小結(jié) 功能,、測試和監(jiān)控是程序開發(fā)的三板斧,，很多工程師可以將功能做的盡善盡美，也了解一些測試方面的知識,，可是在監(jiān)控這個(gè)方向上基本處于大腦空白。錯(cuò)誤日志的收集,、整理算是監(jiān)控的一個(gè)小部分,，但是它對我們了解網(wǎng)站穩(wěn)定性至關(guān)重要。文中有忽略的地方希望讀者可以補(bǔ)充,，錯(cuò)誤的地方還望斧正,。 拓展閱讀 基于window.onerror事件 建立前端錯(cuò)誤日志 by Dx. Yang 構(gòu)建web前端異常監(jiān)控系統(tǒng)–FdSafe by 石破 JavaScript Source Map 詳解 by 阮一峰 HTML5標(biāo)準(zhǔn)-window.onerror MSDN-window.onerror MDN-window.onerror 網(wǎng)絡(luò)錯(cuò)誤日志 |
|
|
