前端代碼異常日誌收集與監控

在複雜的網絡環境和瀏覽器環境下，自測、QA測試以及 Code Review 都是不夠的，若是對頁面穩定性和準確性要求較高，就必須有一套完善的代碼異常監控體系，本文從前端代碼異常監控的方法和問題着手，儘可能全面地闡述錯誤日誌收集各個階段中可能遇到的阻礙和處理方案。

☞ 收集日誌的方法

平時收集日誌的手段，能夠歸類爲兩個方面，一個是邏輯中的錯誤判斷，爲主動判斷；一個是利用語言給咱們提供的捷徑，暴力式獲取錯誤信息，如 try..catch 和window.onerror。

1. 主動判斷

咱們在一些運算以後，獲得一個指望的結果，然而結果不是咱們想要的

// test.js
function calc(){
  // code...
  return val;
}
if(calc() !== "someVal"){
  Reporter.send({
    position: "test.js::<Function>calc"
    msg: "calc error"
  });
}

這種屬於邏輯錯誤/狀態錯誤的反饋，在接口 status 判斷中用的比較多。

2. try..catch 捕獲

判斷一個代碼段中存在的錯誤：

try {
  init();
  // code...
} catch(e){
  Reporter.send(format(e));
}

以 init 爲程序的入口，代碼中全部同步執行出現的錯誤都會被捕獲，這種方式也能夠很好的避免程序剛跑起來就掛。

3. window.onerror

捕獲全局錯誤：

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

在上面的函數中返回 return true，錯誤便不會暴露到控制檯中。下面是它的參數信息：

/**
 * @param {String}  errorMessage   錯誤信息
 * @param {String}  scriptURI      出錯的文件
 * @param {Long}    lineNumber     出錯代碼的行號
 * @param {Long}    columnNumber   出錯代碼的列號
 * @param {Object}  errorObj       錯誤的詳細信息，Anything
 */
window.onerror = function(errorMessage, scriptURI, lineNumber,columnNumber,errorObj) { 
    // code..
}

window.onerror 算是一種特別暴力的容錯手段，try..catch 也是如此，他們底層的實現就是利用 C/C++ 中的 goto 語句實現，一旦發現錯誤，無論目前的堆棧有多深，無論代碼運行到了何處，直接跑到頂層或者 try..catch 捕獲的那一層，這種一腳踢開錯誤的處理方式並非很好。

☞ 收集日誌存在的問題

收集日誌的目的是爲了及時發現問題，最好日誌可以告訴咱們，錯誤在哪裏，更優秀的作法是，不只告訴錯誤在哪裏，還告訴咱們，如何處理這個錯誤。終極目標是，發現錯誤，自動容錯，這一步是最難的。

1. 無具體報錯信息，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();

咱們指望收集到的日誌是下面這樣具體的信息：

爲了對資源進行更好的配置和管理，咱們一般將靜態資源放到異域上

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

而拿到的結果倒是：

翻開 Chromium 的 WebCore 源碼，能夠看到：

跨域狀況下，返回的結果是 Script error.。

// http://trac.webkit.org/browser/branches/chromium/1453/Source/WebCore/dom/ScriptExecutionContext.cpp#L333
String message = errorMessage;
int line = lineNumber;
String sourceName = sourceURL;
// 已經拿到了全部的錯誤信息，但若是發現是非同源狀況，`sanitizeScriptError` 中複寫錯誤信息
sanitizeScriptError(message, line, sourceName, cachedScript);

舊版 的 WebCore 中只判斷了 securityOrigin()->canRequest(targetURL)，新版中還多了一個 cachedScript 的判斷，能夠看出瀏覽器對這方面的限制愈來愈嚴格。

在本地測試了下：

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

☞ 爲什麼Script error.?

簡單報錯： Script error，目的是避免數據泄露到不安全的域中，一個簡單的例子：

<script src="bank.com/login.html"></script>

上面咱們並無引入一個 js 文件，而是一個 html，這個 html 是銀行的登陸頁面，若是你已經登陸了 bank.com，那 login 頁面就會自動跳轉到 Welcome xxx...，若是未登陸則跳轉到 Please Login...，那麼 JS 報錯也會是 Welcome xxx... is not defined，Please Login... is not defined，經過這些信息能夠判斷一個用戶是否登陸他的銀行賬號，給 hacker 提供了十分便利的判斷渠道，這是至關不安全的。

☞ crossOrigin參數跳過跨域限制

image 和 script 標籤都有 crossorigin 參數，它的做用就是告訴瀏覽器，我要加載一個外域的資源，而且我信任這個資源。

<script src="http://localhost/test.js" crossorigin></script>

然而，卻報錯了：

這是意料之中的錯誤，跨域資源共享策略要求，服務器也設置 Access-Control-Allow-Origin 的響應頭：

header('Access-Control-Allow-Origin: *');

回頭看看咱們 CDN 的資源，

Javascript/CSS/Image/Font/SWF 等這些靜態資源其實都已經早早地加上了 CORS 響應頭。

2. 壓縮代碼沒法定位到錯誤的具體位置

線上的代碼幾乎都是通過打包壓縮的，幾十上百的文件壓縮後打包成一個，並且只有一行。當咱們收到 a is not defined 的時候，若是隻在特定場景下才報錯，咱們根本沒法定位到這個被壓縮的 a 是個什麼東西，那麼此時的錯誤日誌就是無效的。

第一個想到的辦法是利用 sourceMap，利用它能夠定位到壓縮代碼某一點在未壓縮代碼的具體位置。下面是 sourceMap 引入的格式，在代碼的最後一行加入：

//# sourceMappingURL=index.js.map

之前使用的是 ‘//@’ 做爲開頭，如今使用 ‘//#’，然而對於錯誤上報，這玩意兒沒啥用。JS 不能拿到他真實的行數，只能經過 Chrome DevTools 這樣的工具輔助定位，並且並非每一個線上資源都會添加 sourceMap 文件。sourceMap 的用途目前還只能體如今開發階段。

固然，若是理解了 sourceMap 的 VLQ編碼和位置對應關係，也能夠將拿到的日誌進行二次解析，映射到真實路徑位置，這個成本比較高，貌似暫時也沒人嘗試過。

那麼，有什麼辦法，能夠定位錯誤的具體位置，或者說有什麼辦法能夠縮小咱們定位問題的難度呢？

能夠這樣考慮：打包的時候，在每兩個合併的文件之間加上 1000 個空行，最後上線的文件就會變成

(function(){var longCode.....})(); // file 1

// 1000 個空行

(function(){var longCode.....})(); // file 2

// 1000 個空行

(function(){var longCode.....})(); // file 3

// 1000 個空行

(function(){var longCode.....})(); // file 4


var _fileConfig = ['file 1', 'file 2', 'file 3', 'file 4']

若是報錯在第 3001 行，

window.onerror = function(msg, url, line, col, error){
  // line = 3001
  var lineNum = line;
  console.log("錯誤位置：" + _fileConfig[parseInt(lineNum / 1000) - 1]); 
  // -> "錯誤位置：file 3"
};

能夠計算出，錯誤出如今第三個文件中，範圍就縮小了不少。

3. error 事件的註冊

屢次註冊 error 事件，不會重複執行多個回調：

var fn = window.onerror = function() {
  console.log(arguments);
};
window.addEventListener("error", fn);
window.addEventListener("error", fn);

觸發錯誤以後，上面代碼的結果爲：

window.onerror 和 addEventListener 都執行了，並只執行了一次。

4. 收集日誌的量

沒有必要將全部的錯誤信息所有送到 Log 中，這個量太大了。若是網頁 PV 有 1kw，那麼一個必現錯誤發送的 log 信息將有 1kw 條，大約一個 G 的日誌。咱們能夠給 Reporter 函數添加一個採樣率：

function needReport (sampling){
  // sampling: 0 - 1
  return Math.random() <= sampling;
}
Reporter.send = function(errInfo, sampling) {
  if(needReport(sampling || 1)){
    Reporter._send(errInfo);
  }
};

這個採樣率能夠按需求來處理，能夠同上，使用一個隨機數，也可使用 cookie 中的某個字段（如 nickname）的最後一個字母/數字來斷定，也能夠將用戶的 nickname 進行 hash 計算，再經過最後一位的字母/數字來判斷，總之，方法是不少的。

☞ 收集日誌布點位置

爲了更加精準的拿到錯誤信息，有效地統計錯誤日誌，咱們應該更多地採用主動式埋點，好比在一個接口的請求中：

// Module A Get Shops Data
$.ajax({
  url: URL,
  dataType: "jsonp",
  success: function(ret) {
    if(ret.status === "failed") {
      // 埋點 1
      return Reporter.send({
        category: "WARN",
        msg: "Module_A_GET_SHOPS_DATA_FAILED"
      });
    }
    if(!ret.data || !ret.data.length) {
      // 埋點 2
      return Reporter.send({
        category: "WARN",
        msg: "Module_A_GET_SHOPS_DATA_EMPTY"
      });
    }
  },
  error: function() {
    // 埋點 3
    Reporter.send({
      category: "ERROR",
      msg: "Module_A_GET_SHOPS_DATA_ERROR"
    });
  }
});

上面咱們精準地佈下了三個點，描述十分清晰，這三個點會對咱們後續排查線上問題提供十分有利的信息。

☞ 關於 try..catch 的使用

對於 try..catch 的使用，個人建議是：能不用，儘可能不要用。JS代碼都是本身寫出來的，哪裏會出現問題，會出現什麼問題，心中應該都有個譜，平時用到 try..catch 的通常只有兩個地方：

// JSON 格式不對
try{
  JSON.parse(JSONString);
}catch(e){}

// 存在不可 decode 的字符
try{
  decodeComponentURI(string);
}catch(e){}

相似這樣的錯誤都是不太可控的。能夠在使用到 try..catch 的地方思考是否可使用其餘方式作兼容。感謝 EtherDream 的補充。

☞ 關於 window.onerror 的使用

能夠嘗試以下代碼：

// test.js
throw new Error("SHOW ME");
window.onerror = function(){
  console.log(arguments);
  // 阻止在控制檯中打印錯誤信息
  return true;
};

上面的代碼直接報錯了，沒有繼續往下執行。頁面中可能有好幾個 script 標籤，可是  這個錯誤監聽必定要放到最前頭！window.onerror

☞ 錯誤的警報與提示

何時該警報？不能有錯就報。上面也說了，由於網絡環境和瀏覽器環境因素，複雜頁面咱們容許千分之一的錯誤率。日誌處理後的數據圖：

圖中有兩根線，橙色線是今日的數據，淺藍色線是往日平均數據，每隔 10 分鐘產生一條記錄，橫座標是 0-24 點的時間軸，縱座標是錯誤量。能夠很明顯的看出，在凌晨一兩點左右，服務出現了異常，錯誤信息是平均值的十幾倍，那麼這個時候就改報警了。

報警的條件能夠設置得嚴苛一點，由於誤報是件很煩人的事情，短信、郵件、軟件等信息轟炸，有的時候仍是大半夜。那麼，通常知足以下條件能夠報警：

• 錯誤超過閾值，好比 10分鐘最多容許 100 個錯誤，結果超過了 100
• 錯誤超過平均值的 10 倍，超過平均值就報警，這個邏輯顯然不正確，可是超過了平均值的 10 倍，基本能夠認定服務出問題了
• 在歸入對比以前，要過濾同 IP 出現的錯誤，好比一個錯誤出如今 for 循環或者 while 循環中，再好比一個用戶在蹲點搶購，不停的刷新

☞ 友好的錯誤提示

對比下面兩條日誌，catch 的錯誤日誌：

Uncaught ReferenceError: vd is not defined

自定義的錯誤日誌：

「生日模塊中獲取後端接口信息時，eval 解析出錯，錯誤內容爲：vd is not defined.」
該錯誤在最近 10 分鐘內出現 1000 次，這個錯誤往日的平均出錯量是 50 次 / 10 分鐘

☞ 網絡錯誤日誌工做草案

W3C Web Performance工做組發佈了網絡錯誤日誌工做草案。該文檔定義了一個機制，容許Web站點聲明一個網絡錯誤彙報策略，瀏覽器等用戶代理能夠利用這一機制，彙報影響資源正確加載的網絡錯誤。該文檔還定義了一個錯誤報告的標準格式及其在瀏覽器和Web服務器之間的傳輸機制。

詳細草案：http://www.w3.org/TR/2015/WD-network-error-logging-20150305/

☞ 小結

功能、測試和監控是程序開發的三板斧，不少工程師能夠將功能作的盡善盡美，也瞭解一些測試方面的知識，但是在監控這個方向上基本處於大腦空白。錯誤日誌的收集、整理算是監控的一個小部分，可是它對咱們瞭解網站穩定性相當重要。文中有忽略的地方但願讀者能夠補充，錯誤的地方還望斧正。