在復(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.js 
function calc(){  // code... 
  return val;}if(calc() !== "someVal"){ Reporter.send({ position: "test.js::<Function>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ò)誤都會被捕獲，這種方式也可以很好的避免程序剛跑起來就掛。

3. window.onerror

捕獲全局錯(cuò)誤：

window.onerror = function() {  var errInfo = format(arguments);  Reporter.send(errInfo);  return true;}; 

在上面的函數(shù)中返回 return true，錯(cuò)誤便不會暴露到控制臺中。下面是它的參數(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

<!-- http://barret/test.html --> 
<script>  window.onerror = function(){    console.log(arguments);  };</script> 
<script src="http://barret/test.js"></script> 
 
test.js 
 
// http://barret/test.js 
function test(){  ver a = 1;  return a+1;}test(); 

我們期望收集到的日志是下面這樣具體的信息：

為了對資源進(jìn)行更好的配置和管理，我們通常將靜態(tài)資源放到異域上

<!-- http://barret/test.html --> 
<script>  window.onerror = function(){    console.log(arguments);  };</script> 
<script src="http://localhost/test.js"></script> 

而拿到的結(jié)果卻是：

翻開 Chromium 的 WebCore 源碼，可以看到：

跨域情況下，返回的結(jié)果是 Script error.。

舊版 的 WebCore 中只判斷了 securityOrigin()->canRequest(targetURL)，新版中還多了一個(gè) cachedScript 的判斷，可以看出瀏覽器對這方面的限制越來越嚴(yán)格。

在本地測試了下：

可見在 file:// 協(xié)議下，securityOrigin()->canRequest(targetURL) 也是 false。

 為何Script error.?

簡單報(bào)錯(cuò)： Script error，目的是避免數(shù)據(jù)泄露到不安全的域中，一個(gè)簡單的例子：

上面我們并沒有引入一個(gè) js 文件，而是一個(gè) html，這個(gè) html 是銀行的登錄頁面，如果你已經(jīng)登錄了 bank.com，那 login 頁面就會自動(dòng)跳轉(zhuǎn)到 Welcome xxx...，如果未登錄則跳轉(zhuǎn)到 Please Login...，那么 JS 報(bào)錯(cuò)也會是 Welcome xxx... is not defined，Please Login... is not defined，通過這些信息可以判斷一個(gè)用戶是否登錄他的銀行帳號，給 hacker 提供了十分便利的判斷渠道，這是相當(dāng)不安全的。

☞ crossOrigin參數(shù)跳過跨域限制

image 和 script 標(biāo)簽都有 crossorigin 參數(shù)，它的作用就是告訴瀏覽器，我要加載一個(gè)外域的資源，并且我信任這個(gè)資源。

然而，卻報(bào)錯(cuò)了：

這是意料之中的錯(cuò)誤，跨域資源共享策略要求，服務(wù)器也設(shè)置 Access-Control-Allow-Origin 的響應(yīng)頭：

回頭看看我們 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 引入的格式，在代碼的***一行加入：

以前使用的是 ‘//@’ 作為開頭，現(xiàn)在使用 ‘//#’，然而對于錯(cuò)誤上報(bào)，這玩意兒沒啥用。JS 不能拿到他真實(shí)的行數(shù)，只能通過 Chrome DevTools 這樣的工具輔助定位，而且并不是每個(gè)線上資源都會添加 sourceMap 文件。sourceMap 的用途目前還只能體現(xiàn)在開發(fā)階段。

當(dāng)然，如果理解了 sourceMap 的 VLQ編碼和位置對應(yīng)關(guān)系，也可以將拿到的日志進(jìn)行二次解析，映射到真實(shí)路徑位置，這個(gè)成本比較高，貌似暫時(shí)也沒人嘗試過。

那么，有什么辦法，可以定位錯(cuò)誤的具體位置，或者說有什么辦法可以縮小我們定位問題的難度呢？

可以這樣考慮：打包的時(shí)候，在每兩個(gè)合并的文件之間加上 1000 個(gè)空行，***上線的文件就會變成

(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 4 
 
 
var _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[lineNum % 1000 - 1]); // -> "錯(cuò)誤位置：file 3" 
}; 

可以計(jì)算出，錯(cuò)誤出現(xiàn)在第三個(gè)文件中，范圍就縮小了很多。

3. error 事件的注冊

多次注冊 error 事件，不會重復(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)會對我們后續(xù)排查線上問題提供十分有利的信息。

關(guān)于 try..catch 的使用

對于 try..catch 的使用，我的建議是：能不用，盡量不要用。JS代碼都是自己寫出來的，哪里會出現(xiàn)問題，會出現(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 的地方思考是否可以使用其他方式做兼容。

關(guān)于 window.onerror 的使用

可以嘗試如下代碼：

上面的代碼直接報(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.w3.org/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ò)誤的地方還望斧正。