如何监控网页崩溃?

如何监控网页崩溃?

崩溃和卡顿有何差别?

卡顿也就是网页暂时响应比较慢,JS 可能无法及时执行,这也是上篇网页卡顿监控所依赖的技术点。

但崩溃就不一样了,网页都崩溃了,页面看不见了,JS 都不运行了,还有什么办法可以监控网页的崩溃,并将网页崩溃上报呢?

但,天无绝人之路,方法总是有的。

load 与 beforeunload 事件

搜遍互联网,几乎找不到方法,最终碰上了这篇文章。本文利用 window 对象的 load 和 beforeunload 事件实现了网页崩溃的监控。

http://jasonjl.me/blog/2015/06/21/taking-action-on-browser-crashes/jasonjl.me

window.addEventListener('load', function () {
  sessionStorage.setItem('good_exit', 'pending');
  setInterval(function () {
    sessionStorage.setItem('time_before_crash', new Date().toString());
  }, 1000);
});

window.addEventListener('beforeunload', function () {
  sessionStorage.setItem('good_exit', 'true');
});

if(sessionStorage.getItem('good_exit') &&
   sessionStorage.getItem('good_exit') !== 'true') {
  /*
         insert crash logging code here
     */
  alert('Hey, welcome back from your crash, looks like you crashed on: ' + sessionStorage.getItem('time_before_crash'));
}

一图胜千言:

img使用 load 和 beforeunload 事件实现崩溃监控

这个方案巧妙的利用了页面崩溃无法触发 beforeunload 事件来实现的。

在页面加载时(load 事件)在 sessionStorage 记录 good_exit 状态为 pending,如果用户正常退出(beforeunload 事件)状态改为 true,如果 crash 了,状态依然为 pending,在用户第2次访问网页的时候(第2个load事件),查看 good_exit 的状态,如果仍然是 pending 就是可以断定上次访问网页崩溃了!

但这个方案有问题:

  1. 采用 sessionStorage 存储状态,但通常网页崩溃/卡死后,用户会强制关闭网页或者索性重新打开浏览器,sessionStorage 存储但状态将不复存在;
  2. 如果将状态存储在 localStorage 甚至 Cookie 中,如果用户先后打开多个网页,但不关闭,good_exit 存储的一直都是 pending,完了,每有一次网页打开,就会有一个 crash 上报。

全民直播 一开始采用的就是这个方案,发现就算页面做了优化,crash 不下降,与 PV 保持比例,才意识到这个方案的问题之处。

基于 Service Worker 的崩溃统计方案

随着 PWA 概念的流行,大家对 Service Worker 也逐渐熟悉起来。基于以下原因,我们可以使用 Service Worker 来实现网页崩溃的监控:

  1. Service Worker 有自己独立的工作线程,与网页区分开,网页崩溃了,Service Worker 一般情况下不会崩溃;
  2. Service Worker 生命周期一般要比网页还要长,可以用来监控网页的状态;
  3. 网页可以通过 navigator.serviceWorker.controller.postMessage API 向掌管自己的 SW 发送消息。

基于以上几点,我们可以实现一种基于心跳检测的监控方案:

img

  • p1:网页加载后,通过 postMessage API 每 5s 给 sw 发送一个心跳,表示自己的在线,sw 将在线的网页登记下来,更新登记时间;
  • p2:网页在 beforeunload 时,通过 postMessage API 告知自己已经正常关闭,sw 将登记的网页清除;
  • p3:如果网页在运行的过程中 crash 了,sw 中的 running 状态将不会被清除,更新时间停留在奔溃前的最后一次心跳;
  • sw:Service Worker 每 10s 查看一遍登记中的网页,发现登记时间已经超出了一定时间(比如 15s)即可判定该网页 crash 了。

一些简化后的检测代码,给大家作为参考:

// 页面 JavaScript 代码
if (navigator.serviceWorker.controller !== null) {
  let HEARTBEAT_INTERVAL = 5 * 1000; // 每五秒发一次心跳
  let sessionId = uuid();
  let heartbeat = function () {
    navigator.serviceWorker.controller.postMessage({
      type: 'heartbeat',
      id: sessionId,
      data: {} // 附加信息,如果页面 crash,上报的附加数据
    });
  }
  window.addEventListener("beforeunload", function() {
    navigator.serviceWorker.controller.postMessage({
      type: 'unload',
      id: sessionId
    });
  });
  setInterval(heartbeat, HEARTBEAT_INTERVAL);
  heartbeat();
}
  • sessionId 本次页面会话的唯一 id;
  • postMessage 附带一些信息,用于上报 crash 需要的数据,比如当前页面的地址等等。
const CHECK_CRASH_INTERVAL = 10 * 1000; // 每 10s 检查一次
const CRASH_THRESHOLD = 15 * 1000; // 15s 超过15s没有心跳则认为已经 crash
const pages = {}
let timer
function checkCrash() {
  const now = Date.now()
  for (var id in pages) {
    let page = pages[id]
    if ((now - page.t) > CRASH_THRESHOLD) {
      // 上报 crash
      delete pages[id]
    }
  }
  if (Object.keys(pages).length == 0) {
    clearInterval(timer)
    timer = null
  }
}

worker.addEventListener('message', (e) => {
  const data = e.data;
  if (data.type === 'heartbeat') {
    pages[data.id] = {
      t: Date.now()
    }
    if (!timer) {
      timer = setInterval(function () {
        checkCrash()
      }, CHECK_CRASH_INTERVAL)
    }
  } else if (data.type === 'unload') {
    delete pages[data.id]
  }
})

都挺简单的代码,不细说了。

方案的可行性

兼容性:

Service Worker 的普及率已经相当高了,鉴于国内各种浏览器都是 Chrome 内核,而且版本已经在 Chrome 45 以上,已经覆盖了相当一部分用户。作为监控,数据覆盖大部分就好。

imgService Worker 兼容性

可靠性:

这应该是我目前已知可以相对准确判断出网页崩溃的方式了。不过我们的方案还在测试环境,上线一段时间后再给大家共享数据。

对浏览器厂商的建议

题图的 Crash 列表,可以在 Chrome 中访问 chrome://crashes/ 看到,如果厂商可以提供一个 API,在页面打开时,可以获知用户上一次崩溃的信息就很棒了!

编辑于 2018-07-22

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: Linux 系统的内核崩溃是指内核在运行过程中出现了无法处理的异常错误,导致系统无法继续运行。 要监控内核崩溃,可以使用以下方法: 1. 使用 dmesg 命令查看内核日志。在内核崩溃时,可以在 dmesg 输出的日志中看到崩溃信息。 2. 使用 kdump 工具记录内核崩溃信息。kdump 是一个用于在内核崩溃时自动生成内核崩溃转储(dump)文件的工具。这些文件包含了在内核崩溃时的内存状态,可以用于分析崩溃原因。 3. 使用 kprobes 工具在运行时追踪内核函数调用和返回。kprobes 可以帮助我们定位内核崩溃发生时调用的函数以及参数,有助于分析崩溃原因。 4. 使用 kgdb 工具在运行时调试内核。kgdb 可以让我们在内核崩溃时暂停运行,以便我们分析崩溃的原因和位置。 通过以上方法,我们就可以在 Linux 系统中监控内核崩溃并分析崩溃原因。 ### 回答2: 对于Linux内核崩溃监控,可以采取以下几种方法。 首先,Linux内核崩溃常见的原因有内存错误、设备驱动错误、硬件故障等。因此,我们可以通过设置内核的panic参数来监控内核崩溃情况。Panic参数控制着内核在遇到严重错误时自动触发崩溃,并生成一个内核转储文件(也称为core dump),该文件可以用于分析崩溃原因。 其次,可以使用系统工具或第三方工具来监控内核崩溃。比如,在Linux系统中,可以使用dmesg命令查看系统的内核日志,检查是否有内核崩溃的相关信息。另外,一些监控工具如ELK Stack、Prometheus等也可以通过收集内核日志来实时监控内核崩溃情况。 此外,内核崩溃也可以通过内核oops(out of panic situation)来监控和分析。oops是Linux内核在遇到一些非致命错误时打印的错误信息,它可以提供有关内核崩溃的线索。我们可以通过系统日志(如/var/log/messages)或通过dmesg来查看和分析oops信息,从而得到内核崩溃的一些关键信息。 最后,为了更加深入地监控和分析内核崩溃,可以使用专业的调试工具,如GDB(GNU Debugger),通过attach到崩溃的内核进程来进行调试。使用GDB,可以定位到内核崩溃的具体位置和原因,以便进一步修复和优化。 综上所述,通过设置panic参数、使用系统工具或第三方工具、分析oops信息以及使用GDB等调试工具,可以监控和分析Linux内核的崩溃情况,从而及时发现问题并进行处理。 ### 回答3: Linux内核崩溃时,我们可以通过以下方法进行监控和调试。 1. 内核转储(Kernel Dump):当内核崩溃时,可以将内核转储保存在硬盘上,以便后续分析。可以通过设置合适的参数来配置内核转储,例如在/etc/kdump.conf中设置保存路径和大小等参数。转储文件保存后,可以使用工具如crash来分析转储文件,查找内核崩溃的原因。 2. 内核日志记录(Kernel Logging):内核崩溃时,可以将重要的信息输出到内核日志中。我们可以通过查看内核日志来了解崩溃的原因。内核日志一般保存在/var/log/messages或/var/log/kern.log中,可以使用工具如dmesg或journalctl来查看这些日志。 3. 监控工具:Linux提供了一些监控工具用于检测内核崩溃,例如SystemTap和kdump。SystemTap是一个强大的运行时跟踪和分析工具,可以实时监控系统状态和内核崩溃信息。kdump是一个用于处理内核崩溃的工具,当发生内核崩溃时,可以自动保存转储文件并触发重启。 4. 调试器和追踪工具:除了以上方法,我们还可以使用调试器和追踪工具来分析内核崩溃。调试器如gdb可以查看内核内部的数据结构和变量,以及调用堆栈信息。追踪工具如ftrace和perf可以跟踪内核函数的调用和性能信息,帮助我们定位内核崩溃的原因。 总之,通过以上方法,我们可以监控和调试Linux内核崩溃,找到崩溃原因并采取相应的解决措施。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值