关于前端:一文彻底搞懂前端监控

关注公众号“执鸢者”，回复“红宝书”获取“javaScript 高级程序第四版（pdf）”及大量前端学习材料。

一、前端监控现状

近年来，前端监控是越来越火，目前曾经有很多成熟的产品供咱们抉择应用，如下图所示

有这么多监控平台，那为什么还要学习搞前端监控？

• 一方面人家是要钱的
• 另一方面本人的我的项目须要定制化的性能。

二、前端监控的目标

1. 晋升用户体验
2. 更快的发现发现异常、定位异样、解决异样
3. 理解业务数据，领导产品升级——数据驱动的思维

三、前端监控的流程

3.1 采集

前端监控的第一个步骤就是数据采集，采集的信息蕴含环境信息、性能信息、异样信息、业务信息。

3.1.1 环境信息

环境信息是每个监控零碎必备的内容，毕竟排查问题的时候须要晓得来自哪个页面、浏览器是谁、操作用户是谁……, 这样能力疾速定位问题，解决问题。个别这些常见的环境信息次要蕴含：

1. url：正在监控的页面，该页面可能会呈现性能、异样问题。获取形式为：<br/>
   window.location.href<br/>
2. ua: 拜访该页面时该用户的 userAgent 信息，蕴含操作系统和浏览器的类型、版本等。获取形式为：<br/>
   window.navigator.userAgent
3. token：记录以后用户是谁。通过记录该用户是谁。<br/>
   一方面不便将该用户的所有监控信息建立联系，不便数据分析；<br/>
   另一方面通过该标识能够查看该用户的所有操作，不便复现问题。<br/>

3.1.2 性能信息

页面的性能间接影响了用户留存率，，Google DoubleClick 钻研表明：如果一个挪动端页面加载时长超过 3 秒，用户就会放弃而来到。BBC 发现网页加载时长每减少 1 秒，用户就会散失 10%。，Google DoubleClick 钻研表明：如果一个挪动端页面加载时长超过 3 秒，用户就会放弃而来到。BBC 发现网页加载时长每减少 1 秒，用户就会散失 10%。所以咱们的谋求就是进步页面的性能，为了进步性能须要监控哪些指标呢？

3.1.2.1 指标分类

指标有很多，我总结为以下两个方面：网络层面和页面展现层面。
一、网络层面
从网络层面来看波及的指标有：重定向耗时、DNS 解析耗时、TCP 连贯耗时、SSL 耗时、TTFB 网络申请耗时、数据传输耗时、资源加载耗时……, 各个指标的解释如下表所示：

二、页面展现层面

页面展现层面的指标是针对用户体验提出的几个指标，蕴含 FP、FCP、LCP、FMP、DCL、L 等，这几个指标其实就是 chrome 浏览器中 performance 模块的指标（如图所示）。

各个指标的解释如下表所示。

3.1.2.2 指标求解

上述这么多指标该怎么获取呢？浏览器给咱们留了相应的接口——神奇的 window.performance，通过该接口能够获取一些列与性能相干的参数，上面以 https://baidu.com 为例来看一下与这些指标相干的参数：

window.performance 中的 timing 属性中的内容不就是为了求解上述指标所须要的值吗？看着下面的属性值再对应上面的 performance 拜访流程图，整个过程是不是高深莫测。

有了下面的值咱们就一起求解上述的指标：
一、网络层面

二、页面展现层面

Google 工程师始终在推动以用户为核心的性能指标，所以页面展现层面的变动较大，求解形式稍有不同：

1. FP 和 FCP

通过 window.performance.getEntriesByType(‘paint’)的形式获取

const paint = window.performance.getEntriesByType('paint');
const FP = paint[0].startTime,
const FCP = paint[1].startTime,

1. LCP

function getLCP() {
    // 减少一个性能条目标观察者
    new PerformanceObserver((entryList, observer) => {let entries = entryList.getEntries();
        const lastEntry = entries[entries.length - 1];
        observer.disconnect();
        console.log('LCP', lastEntry.renderTime || lastEntry.loadTime);
    }).observe({entryTypes: ['largest-contentful-paint']});
}

1. FMP

function getFMP() {
    let FMP;
    new PerformanceObserver((entryList, observer) => {let entries = entryList.getEntries();
        observer.disconnect();
        console.log('FMP', entries);
    }).observe({entryTypes: ['element']});
}

1. DCL

domContentLoadEventEnd – fetchStart

1. L

loadEventStart – fetchStart

1. TTI

domInteractive – fetchStart

1. FID

function getFID() {new PerformanceObserver((entryList, observer) => {let firstInput = entryList.getEntries()[0];
        if (firstInput) {
            const FID = firstInput.processingStart - firstInput.startTime;
            console.log('FID', FID);
        }
        observer.disconnect();}).observe({type: 'first-input', buffered: true});
}

3.1.3 异样信息

对于网站来说，异样信息是最致命、最影响用户体验的问题，须要重点监控。对于异样信息能够分为两类：运行时谬误、接口谬误。上面就别离来唠一唠这两类谬误。

一、运行时谬误

当 JavaScript 运行时有可能会产生谬误，可归类为七种：语法错误、类型谬误、范畴谬误、援用谬误、eval 谬误、URL 谬误、资源加载谬误。为了捕捉代码谬误，须要思考两类场景：非 Promise 场景和 Promise 场景，因为两种场景捕捉谬误的策略不同。

1. 非 Promise 场景

非 Promise 场景可通过监听 error 事件来捕捉谬误。对于 error 事件捕捉的谬误分为两类：资源谬误和代码谬误。资源谬误指的就是 js、css、img 等未加载，该谬误只能在捕捉阶段获取到，且为资源谬误时 event.target.localName 存在值（用此辨别资源谬误与代码谬误）；代码谬误指的就是语法错误、类型谬误等这一类谬误，能够获取代码谬误的信息、堆栈等，用于排查谬误。

export function listenerError() {window.addEventListener('error', (event) => {if (event.target.localName) {console.log('这是资源谬误', event);
        }
        else {console.log('这是代码谬误', event);
        }
    }, true)
}

2.Promise 场景

Promise 场景的解决形式有所不同，当 Promise 被 reject 且没有 reject 处理器的时候，会触发 unhandlerejection 事件，所以通过监听 unhandlerejection 的事件来捕捉谬误。

export function listenerPromiseError() {window.addEventListener('unhandledrejection', (event) => {console.log('这是 Promise 场景中谬误', event);
    })
}

二、接口谬误

对于浏览器来说，所有的接口均是基于 XHR 和 Fetch 实现的，为了捕捉接口中的谬误，能够通过重写该办法，而后通过接口返回的信息来判断以后接口的情况，上面以 XHR 为例来展现封装过程。

function newXHR() {
    const XMLHttpRequest = window.XMLHttpRequest;
    const oldXHROpen = XMLHttpRequest.prototype.open;
    XMLHttpRequest.prototype.open = (method, url, async) => {
        // 做一些本人的数据上报操作
        return oldXHROpen.apply(this, arguments);
    }

    const oldXHRSend = XMLHttpRequest.prototype.send;
    XMLHttpRequest.prototype.send = (body) => {
        // 做一些本人的数据上报操作
        return oldXHRSend.apply(this, arguments);
    }
}

3.1.4 业务信息

每个产品都会有本人的业务信息，例如用户在线时长、pv、uv、用户散布等，通过获取这些业务信息能力更加分明的理解目前产品的情况，以便产品经理更好的去布局产品的将来方向。因为每个产品业务信息多种多样，小伙伴本能够依照本人的需要进行撰写代码，此处我就不再赘述。

3.2 上报

对于上报的形式无外乎两种：一种是 Ajax 的形式上报；另一种是通过 Image 的模式进行上报。目前很多大厂采纳的上报形式均是通过一个 1 * 1 像素的的 gif 图片进行上报，既然人家都采纳该种策略，那咱们就来唠一唠上面两个问题。

• 为什么采纳 Image 的形式上报?<br/>

  1. 没有跨域问题。因为数据服务器和后端服务器大概率是不同的域名，若采纳 Ajax 的形式进行解决还要解决跨域问题，否则数据会被浏览器拦挡。<br/>
  2. 不会阻塞页面加载，只需 new Image 对象即可。
• 图片类型很多，为什么采纳 gif 这种格局进行上报？<br/>
  其实归结为一个字——小。对于 1 *1px 的图片，BMP 构造的文件须要 74 字节，PNG 构造的文件须要 67 字节，GIF 构造的文件只须要 43 字节。同样的响应，GIF 能够比 BMP 节约 41% 的流量，比 PNG 节约 35% 的流量，所以抉择 gif 进行上报。

3.3 剖析

日志上报之后须要进行荡涤，获取本人所须要内容，并将剖析内容进行存储。依据数据量的大小可分为两种形式：单机和集群。

一、单机<br/>

访问量小、日志少的网站能够采纳单机的形式对数据进行剖析，例如用 node 读取日志文件，而后通过日志文件中获取所须要的信息，最终将解决的信息存储到数据库中。<br/>

二、集群<br/>

很多产品的访问量很大，日志很多，此时就须要利用 Hadoop 进行分布式解决，获取最终处理结果，其解决流程图如下所示：

依据本人的日志量级决定本人的剖析形式，适合的就是最好的，不必一味谋求最优的、最先进的解决形式。

3.4 报警

当异样类型超多肯定阈值之后须要进行报警告诉，让对应的工作人员去解决问题，及时止损。依据报警的级别不同，能够抉择不同的报警形式。

1. 邮件——一般报警
2. 短信——重大报警，已影响局部业务
3. 电话——特地重大，例如零碎已宕机

1. 如果感觉这篇文章还不错，来个分享、点赞、吧，让更多的人也看到

2. 关注公众号执鸢者，支付学习材料，定期为你推送原创深度好文

参考

http://www.alloyteam.com/2020…
https://www.colabug.com/2019/…