从零开始搞监控系统（7）——监控页面奔溃原创
目录：
前言
页面奔溃包含两种场景，第一种是浏览器在加载网页时遇到问题导致的奔溃，另一种是因为脚本渲染出错导致页面空白无内容的奔溃。
前段时间运营抱怨有张活动页出现了空白（第二种奔溃场景），导致用户无法访问，希望我们能主动监控到这种情况，而不是通过用户的上报。
后面和运维沟通，他那边目前只能监控接口的访问情况，无法监控静态资源，若要监控得自己想办法实现。
首先想到的自然是利用现有的监控系统来了解页面空白情况，例如某个项目5分钟内没有监控日志，那就认为出现了页面奔溃。
急匆匆的写了段定时任务，放到线上运行，发现这样监控会有一个很大漏洞。因为某些项目的访问量本来就不高，5分钟内没有日志是属于正常情况，所以只得作罢。
一、页面奔溃
首先来解决第一种奔溃场景，在网上搜了些关键字，发现了些有用的资料，例如如何监控网页崩溃，前端崩溃监控优化历程等。
这些资料提供了一个全新的思路来监控页面奔溃，基于Service Worker的崩溃统计方案。
简单地说就是一种心跳检测机制，在页面的脚本中创建Service Worker工作线程，然后定时地向该线程发送消息，即使网页奔溃了，线程还能存活。
在线程中接收消息并比对时间，当间隔时间大于15秒时，就认为超时没有心跳了，页面处于奔溃阶段，向监控系统上报相关信息。
在我操刀实现的时候，Service Worker没有运行成功，后面就改成了Web Worker。
工作线程的代码保存在sw.js（如下所示），在参考一篇Web Workers的文章时，他提到在线程中可以navigator对象，该对象正好有个sendBeacon()方法，可用于跨域请求。
但是没想到线程中用的WorkerNavigator，并没有该方法，后面无奈改成了fetch()。
但是有跨域问题，要么在响应时加上跨域头，要么就无视直接发送，因为浏览器只会拦截响应不会拦截请求。
var CHECK_CRASH_INTERVAL = 10 * 1000; // 每 10s 检查一次
var CRASH_THRESHOLD = 15 * 1000; // 15s 超过15s没有心跳则认为已经 crash
var pages = {}, timer;
function send(param) {
fetch(param.src);
};
function checkCrash() {
var now = Date.now()
for (var id in pages) {
var page = pages[id];
if ((now - page.t) > CRASH_THRESHOLD) {
// 上报 crash
delete pages[id];
send(page.data);
}
}
if (Object.keys(pages).length == 0) {
clearInterval(timer)
timer = null
}
}
self.addEventListener('message', (e) => {
var data = e.data;
if (data.type === 'heartbeat') {
// console.log('heartbeat');
pages[data.id] = {
t: Date.now(),
data: data.data
}
if (!timer) {
timer = setInterval(function () {
checkCrash()
}, CHECK_CRASH_INTERVAL)
}
} else if (data.type === 'unload') {
delete pages[data.id]
}
})在网页中加的代码如下，由于Worker加载的脚本有同源策略的限制，所以脚本和页面需要在相同的域名中。
function monitorCrash(param) {
var isCrash = param.isCrash;
if (!isCrash || !window.Worker) return;
var worker = new Worker("/sw.js");
var HEARTBEAT_INTERVAL = 5 * 1000; // 每五秒发一次心跳
var sessionId = getIdentity();
var heartbeat = function () {
worker.postMessage({
type: "heartbeat",
id: sessionId,
data: {
//在页面奔溃时，上报数据，需要将上报地址一起传递
src: param.src
}
});
};
window.addEventListener("beforeunload", function () {
worker.postMessage({
type: "unload",
id: sessionId
});
});
var timer = setInterval(heartbeat, HEARTBEAT_INTERVAL);
heartbeat();
}上线后先在管理后台做测试，管理后台使用的是PC浏览器，马上就发现了比较严重的误报问题。
分析下来有可能是网页在标签栏不活动的时候，影响了定时器的执行，再次活动计算两个时间段的间隔，很有可能超出了15秒，而上报奔溃日志。
鉴于此，在没有完美解决方案之前，暂时将此功能下架。
二、页面空白
再来解决第二种奔溃场景，现在开发都会依托React或Vue等库或框架，而这些都是用脚本来渲染出DOM结构的。
一旦在渲染时出现脚本错误（例如未定义的变量、浏览器不支持的语法等）就会中断渲染，从而就会出现页面无内容的情况。
这类监控并不需要使用Web Worker，只要我的监控SDK在业务脚本之前引入，就能保证监控代码正常运行。
监控原理就是加个定时器，查看渲染容器中是否是空白，若是空白就上报并关闭定时器，否则循环监控。
例如后台管理系统采用的是React，在HTML中会声明一个div元素，内容都会渲染到该元素中。
<div id="root"></div>自定义一个关键DOM的判断条件，如下所示，在定时器中循环执行。
shin.setParam({
validateCrash: () => {
//当root标签中的内容为空时，可认为页面已奔溃
return {
success: document.getElementById("root").innerHTML.length > 0,
prompt: "页面出现空白"
};
}
});此处还有个小坑，就是定时器的运行时机，不能太早，太早判断的话，div元素中肯定没有内容，后面就将判断时机移到了DOMContentLoaded事件中。
下面是监控白屏的主要逻辑，isCrash 是一个监控开关，document.body.clientHeight 是指内容高度与上下内边距的和。
在我们这边的页面中， body 都不会有内边距，所以该判断适用，当然，具体可根据业务场景做自定义的兜底处理。
function monitorCrash(param) {
var isCrash = param.isCrash;
var validateCrash = param.validateCrash;
if (!isCrash) {
return;
}
var HEARTBEAT_INTERVAL = 5 * 1000; // 每五秒发一次心跳
var crashHeartbeat = function () {
var result = validateCrash();
// 符合自定义的奔溃规则
if (result && !result.success) {
handleError({
type: ERROR_CRASH,
desc: {
prompt: result.prompt,
url: location.href
}
});
// 关闭定时器
clearInterval(timer);
// 兜底白屏算法，可根据自身业务定义
} else if (document.body.clientHeight === 0) {
// 查询第一个div
var currentDiv = document.querySelector("div");
// 增加 html 字段是为了验证是否出现了误报
handleError({
type: ERROR_CRASH,
desc: {
prompt: "页面没有高度",
url: location.href,
html: currentDiv ? currentDiv.innerHTML : ""
}
});
clearInterval(timer);
}
};
var timer = setInterval(crashHeartbeat, HEARTBEAT_INTERVAL);
crashHeartbeat(); // 立即执行一次
// 5分钟后自动取消定时器
setTimeout(function () {
// 关闭定时器
clearInterval(timer);
}, 1000 * 300);
}2022-12-07一开始 isCrash 默认标记为 false，也就是关闭监控的，后面默认打开后，线上出现白屏的页面一下子增加了四五百左右。
接下来就是验证上报的白屏是否准确，下面是上报的一条记录，它有一串字符身份信息，例如 syqgpsyz4s。
{
"type": "crash",
"desc": {
"prompt": "页面没有高度",
"url": "https://www.xxx.com/chat.html?matchId=100",
"html": ""
}
}根据身份信息，再去日志明细中查找他的前后动作，发现只有一条记录，也就是既没有脚本错误，也没有接口请求。
再根据此身份去查询性能监控的记录 ID，找出当时静态资源的瀑布图，在此图中，并没有发现资源异常。
但是当我直接请求 url 地址时，却发现有 3 个资源的请求是 404，与正常页面中的 3 个资源做比对，发现两者的随机后缀是不同的。
现在恍然大悟，是 CDN 缓存刷新失败导致的问题，问题马上就定位到了。
还发现另一个问题是因为参数的值导致的白屏，首次使用下来，准确率还是蛮高的。
关于资源瀑布图，还有优化空间，可以将 404 资源标红。同时也发现了静态资源请求错误没有记录的问题。
去掉下面 if 语句中对 event.filename 的判断，因为资源错误是没有 filename 属性的，这样就能将此类资源错误记录在案了。
window.addEventListener(
"error",
function (event) {
var errorTarget = event.target;
// 过滤掉与业务无关的错误
if (event.message === "Script error." || !event.filename) {
return;
}
if (
errorTarget !== window &&
errorTarget.nodeName &&
LOAD_ERROR_TYPE[errorTarget.nodeName.toUpperCase()]
) {
handleError(formatLoadError(errorTarget));
} else {
handleError(
formatRuntimerError(
event.message,
event.filename,
event.lineno,
event.colno,
event.error
)
);
}
},
true //捕获
);2022-12-09 在优化白屏后的几天，发现有误报的情况发生，因为 html 属性值中有内容。
打开这些页面分析，发现有些内容的样式是绝对定位或固定定位，也就是说这些内容并不会撑起 body 的高度。
那么要有高度，就需要等待其他元素渲染，若在上报白屏时，还没渲染成功，那么就有可能误报。
为了验证自己的猜想，去查询了下某条性能记录的资源瀑布图，发现在触发 DOMContentLoaded 时，那些能撑起高度的资源还没加载完成。
经测试发现，当因为脚本错误出现白屏时，两个事件的触发时机会很接近，而如果是正常情况，那么两者会有些时间的间隔。
所以发生白屏时，也能减少因用户快速关闭页面而发生漏报的情况，因此最后决定将上报迁移到 load 事件中。
2022-12-13 在监控白屏时，发现有一类的白屏是由标签栏切换引起的，因为在切换后会先将之前的列表清空，再去请求接口。
在等待数据时就会有那么一段白屏时间差，为了体验好点，其实可以加一些过渡效果，例如加个 loading 等待。
