前端代码异常日志收集与监控

在复杂的网络环境和浏览器环境下，自测、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/

☞ 小结

功能、测试和监控是程序开发的三板斧，不少工程师能够将功能作的尽善尽美，也了解一些测试方面的知识，但是在监控这个方向上基本处于大脑空白。错误日志的收集、整理算是监控的一个小部分，可是它对咱们了解网站稳定性相当重要。文中有忽略的地方但愿读者能够补充，错误的地方还望斧正。