多次注册 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/☞ 小结功能、测试和监控是程序开发的三板斧很多工程师可以将功能做的尽善尽美也了解一些测试方面的知识可是在监控这个方向上基本处于大脑空白。错误日志的收集、整理算是监控的一个小部分但是它对我们了解网站稳定性至关重要。文中有忽略的地方希望读者可以补充错误的地方还望斧正。
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/☞ 小结功能、测试和监控是程序开发的三板斧很多工程师可以将功能做的尽善尽美也了解一些测试方面的知识可是在监控这个方向上基本处于大脑空白。错误日志的收集、整理算是监控的一个小部分但是它对我们了解网站稳定性至关重要。文中有忽略的地方希望读者可以补充错误的地方还望斧正。
