建站
咨詢
售后
建站咨詢
新聞中心
一、前端監(jiān)控現(xiàn)狀
秦都網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián),秦都網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為秦都數(shù)千家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站建設(shè)公司要多少錢，請(qǐng)找那個(gè)售后服務(wù)好的秦都做網(wǎng)站的公司定做！
近年來(lái)，前端監(jiān)控是越來(lái)越火，目前已經(jīng)有很多成熟的產(chǎn)品供我們選擇使用，如下圖所示
有這么多監(jiān)控平臺(tái)，那為什么還要學(xué)習(xí)自研前端監(jiān)控?
- 一方面人家是要錢的
- 另一方面自己的項(xiàng)目需要定制化的功能。
二、前端監(jiān)控的目的
- 提升用戶體驗(yàn)
- 更快的發(fā)現(xiàn)發(fā)現(xiàn)異常、定位異常、解決異常
- 了解業(yè)務(wù)數(shù)據(jù)，指導(dǎo)產(chǎn)品升級(jí)——數(shù)據(jù)驅(qū)動(dòng)的思想
三、前端監(jiān)控的流程
3.1 采集
前端監(jiān)控的第一個(gè)步驟就是數(shù)據(jù)采集，采集的信息包含環(huán)境信息、性能信息、異常信息、業(yè)務(wù)信息。
3.1.1 環(huán)境信息
環(huán)境信息是每個(gè)監(jiān)控系統(tǒng)必備的內(nèi)容，畢竟排查問(wèn)題的時(shí)候需要知道來(lái)自哪個(gè)頁(yè)面、瀏覽器是誰(shuí)、操作用戶是誰(shuí)……,這樣才能快速定位問(wèn)題，解決問(wèn)題。一般這些常見(jiàn)的環(huán)境信息主要包含：
- url：正在監(jiān)控的頁(yè)面，該頁(yè)面可能會(huì)出現(xiàn)性能、異常問(wèn)題。獲取方式為：
window.location.href
- ua:訪問(wèn)該頁(yè)面時(shí)該用戶的userAgent信息，包含操作系統(tǒng)和瀏覽器的類型、版本等。獲取方式為：
window.navigator.userAgent
- token：記錄當(dāng)前用戶是誰(shuí)。通過(guò)記錄該用戶是誰(shuí)。
一方面方便將該用戶的所有監(jiān)控信息建立聯(lián)系，方便數(shù)據(jù)分析;
另一方面通過(guò)該標(biāo)識(shí)可以查看該用戶的所有操作，方便復(fù)現(xiàn)問(wèn)題。
3.1.2 性能信息
頁(yè)面的性能直接影響了用戶留存率，，Google DoubleClick 研究表明：如果一個(gè)移動(dòng)端頁(yè)面加載時(shí)長(zhǎng)超過(guò) 3 秒，用戶就會(huì)放棄而離開(kāi)。BBC 發(fā)現(xiàn)網(wǎng)頁(yè)加載時(shí)長(zhǎng)每增加 1 秒，用戶就會(huì)流失 10%。，Google DoubleClick 研究表明：如果一個(gè)移動(dòng)端頁(yè)面加載時(shí)長(zhǎng)超過(guò) 3 秒，用戶就會(huì)放棄而離開(kāi)。BBC 發(fā)現(xiàn)網(wǎng)頁(yè)加載時(shí)長(zhǎng)每增加 1 秒，用戶就會(huì)流失 10%。所以我們的追求就是提高頁(yè)面的性能，為了提高性能需要監(jiān)控哪些指標(biāo)呢?
3.1.2.1 指標(biāo)分類
指標(biāo)有很多，我總結(jié)為以下兩個(gè)方面：網(wǎng)絡(luò)層面和頁(yè)面展示層面。
一、網(wǎng)絡(luò)層面
從網(wǎng)絡(luò)層面來(lái)看涉及的指標(biāo)有：重定向耗時(shí)、DNS解析耗時(shí)、TCP連接耗時(shí)、SSL耗時(shí)、TTFB網(wǎng)絡(luò)請(qǐng)求耗時(shí)、數(shù)據(jù)傳輸耗時(shí)、資源加載耗時(shí)……,各個(gè)指標(biāo)的解釋如下表所示：
| 指標(biāo) | 解釋 |
|---|---|
| 重定向耗時(shí) | 重定向所耗費(fèi)的時(shí)間 |
| DNS解析耗時(shí) | 瀏覽器輸入網(wǎng)址后首先會(huì)進(jìn)行DNS解析，其可以對(duì)服務(wù)器是否工作作出反饋 |
| TCP連接耗時(shí) | 指建立連接過(guò)程的耗時(shí) |
| SSL連接耗時(shí) | 指數(shù)據(jù)安全性、完整性建立耗時(shí) |
| TTFB 網(wǎng)絡(luò)請(qǐng)求耗時(shí) | 表示瀏覽器接收第一個(gè)字節(jié)的時(shí)間 |
| 數(shù)據(jù)傳輸耗時(shí) | 瀏覽器接收內(nèi)容所耗費(fèi)的時(shí)間 |
| 資源加載耗時(shí) | DOM構(gòu)建完畢后到頁(yè)面加載完畢這段時(shí)間 |
二、頁(yè)面展示層面
頁(yè)面展示層面的指標(biāo)是針對(duì)用戶體驗(yàn)提出的幾個(gè)指標(biāo)，包含F(xiàn)P、FCP、LCP、FMP、DCL、L等，這幾個(gè)指標(biāo)其實(shí)就是chrome瀏覽器中performance模塊的指標(biāo)(如圖所示)。
各個(gè)指標(biāo)的解釋如下表所示。
| 指標(biāo) | 解釋 |
|---|---|
| FP（First Paint） | 首次繪制，標(biāo)記瀏覽器渲染任何在視覺(jué)上不同于導(dǎo)航前屏幕內(nèi)容之內(nèi)容的時(shí)間點(diǎn). |
| FCP（First Contentful Paint） | 首次內(nèi)容繪制，標(biāo)記瀏覽器渲染來(lái)自 DOM 第一位內(nèi)容的時(shí)間點(diǎn)，該內(nèi)容可能是文本、圖像、SVG 甚至 元素. |
| LCP（Largest Contentful Paint） | 最大內(nèi)容渲染，表示可視區(qū)“內(nèi)容”最大的可見(jiàn)元素開(kāi)始出現(xiàn)在屏幕上的時(shí)間點(diǎn)。 |
| FMP（First Meaningful Paint） | 首次有效繪制，表示頁(yè)面的“主要內(nèi)容”開(kāi)始出現(xiàn)在屏幕上的時(shí)間點(diǎn)。它是我們測(cè)量用戶加載體驗(yàn)的主要指標(biāo)。 |
| DCL（DomContentLoaded） | 當(dāng) HTML 文檔被完全加載和解析完成之后，DOMContentLoaded 事件被觸發(fā)，無(wú)需等待樣式表、圖像和子框架的完成加載. |
| L（onLoad） | 當(dāng)依賴的資源全部加載完畢之后才會(huì)觸發(fā) |
| TTI（Time to Interactive） | 可交互時(shí)間，用于標(biāo)記應(yīng)用已進(jìn)入視覺(jué)渲染并能可靠響應(yīng)用戶輸入的時(shí)間點(diǎn) |
| FID（First Input Delay） | 首次輸入延遲，用戶首次和頁(yè)面交互（單擊鏈接、點(diǎn)擊按鈕等）到頁(yè)面響應(yīng)交互的時(shí)間 |
3.1.2.2 指標(biāo)求解
上述這么多指標(biāo)該怎么獲取呢?瀏覽器給我們留了相應(yīng)的接口——神奇的window.performance，通過(guò)該接口可以獲取一些列與性能相關(guān)的參數(shù)，下面以https://baidu.com 為例來(lái)看一下與這些指標(biāo)相關(guān)的參數(shù)：
window.performance中的timing屬性中的內(nèi)容不就是為了求解上述指標(biāo)所需要的值嗎?看著上面的屬性值再對(duì)應(yīng)下面的performance訪問(wèn)流程圖，整個(gè)過(guò)程是不是一目了然。
有了上面的值我們就一起求解上述的指標(biāo)：
一、網(wǎng)絡(luò)層面
| 指標(biāo) | 計(jì)算 |
|---|---|
| 重定向耗時(shí) | redirectEnd - redirectStart |
| DNS解析耗時(shí) | domainLookupEnd - domainLookupStart |
| TCP連接耗時(shí) | connectEnd - connectStart |
| SSL連接耗時(shí) | connectEnd - secureConnectionStart |
| TTFB 網(wǎng)絡(luò)請(qǐng)求耗時(shí) | responseStart - requestStart |
| 數(shù)據(jù)傳輸耗時(shí) | responseEnd - responseStart |
| 資源加載耗時(shí) | loadEventStart - domContentLoadedEventEnd |
二、頁(yè)面展示層面
Google工程師一直在推動(dòng)以用戶為中心的性能指標(biāo)，所以頁(yè)面展示層面的變化較大，求解方式稍有不同：
1.FP和FCP
通過(guò)window.performance.getEntriesByType(‘paint’)的方式獲取
- const paint = window.performance.getEntriesByType('paint');
- const FP = paint[0].startTime,
- const FCP = paint[1].startTime,
2.LCP
- function getLCP() {
- // 增加一個(gè)性能條目的觀察者
- 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']});
- }
3.FMP
- function getFMP() {
- let FMP;
- new PerformanceObserver((entryList, observer) => {
- let entries = entryList.getEntries();
- observer.disconnect();
- console.log('FMP', entries);
- }).observe({entryTypes: ['element']});
- }
4.DCL
- domContentLoadEventEnd – fetchStart
5.L
- loadEventStart – fetchStart
6.TTI
- domInteractive – fetchStart
7.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 異常信息
對(duì)于網(wǎng)站來(lái)說(shuō)，異常信息是最致命、最影響用戶體驗(yàn)的問(wèn)題，需要重點(diǎn)監(jiān)控。對(duì)于異常信息可以分為兩類：運(yùn)行時(shí)錯(cuò)誤、接口錯(cuò)誤。下面就分別來(lái)嘮一嘮這兩類錯(cuò)誤。
一、運(yùn)行時(shí)錯(cuò)誤
當(dāng)JavaScript運(yùn)行時(shí)有可能會(huì)發(fā)生錯(cuò)誤，可歸類為七種：語(yǔ)法錯(cuò)誤、類型錯(cuò)誤、范圍錯(cuò)誤、引用錯(cuò)誤、eval錯(cuò)誤、URL錯(cuò)誤、資源加載錯(cuò)誤。為了捕獲代碼錯(cuò)誤，需要考慮兩類場(chǎng)景：非Promise場(chǎng)景和Promise場(chǎng)景，因?yàn)閮煞N場(chǎng)景捕獲錯(cuò)誤的策略不同。
1.非Promise場(chǎng)景
非Promise場(chǎng)景可通過(guò)監(jiān)聽(tīng)error事件來(lái)捕獲錯(cuò)誤。對(duì)于error事件捕獲的錯(cuò)誤分為兩類：資源錯(cuò)誤和代碼錯(cuò)誤。資源錯(cuò)誤指的就是js、css、img等未加載，該錯(cuò)誤只能在捕獲階段獲取到，且為資源錯(cuò)誤時(shí)event.target.localName存在值(用此區(qū)分資源錯(cuò)誤與代碼錯(cuò)誤);代碼錯(cuò)誤指的就是語(yǔ)法錯(cuò)誤、類型錯(cuò)誤等這一類錯(cuò)誤，可以獲取代碼錯(cuò)誤的信息、堆棧等，用于排查錯(cuò)誤。
- export function listenerError() {
- window.addEventListener('error', (event) => {
- if (event.target.localName) {
- console.log('這是資源錯(cuò)誤', event);
- }
- else {
- console.log('這是代碼錯(cuò)誤', event);
- }
- }, true)
- }
2.Promise場(chǎng)景
Promise場(chǎng)景的處理方式有所不同，當(dāng)Promise被reject且沒(méi)有reject處理器的時(shí)候，會(huì)觸發(fā)unhandlerejection事件，所以通過(guò)監(jiān)聽(tīng)unhandlerejection的事件來(lái)捕獲錯(cuò)誤。
- export function listenerPromiseError() {
- window.addEventListener('unhandledrejection', (event) => {
- console.log('這是Promise場(chǎng)景中錯(cuò)誤', event);
- })
- }
二、接口錯(cuò)誤
對(duì)于瀏覽器來(lái)說(shuō)，所有的接口均是基于XHR和Fetch實(shí)現(xiàn)的，為了捕獲接口中的錯(cuò)誤，可以通過(guò)重寫該方法，然后通過(guò)接口返回的信息來(lái)判斷當(dāng)前接口的狀況，下面以XHR為例來(lái)展示封裝過(guò)程。
- function newXHR() {
- const XMLHttpRequest = window.XMLHttpRequest;
- const oldXHROpen = XMLHttpRequest.prototype.open;
- XMLHttpRequest.prototype.open = (method, url, async) => {
- // 做一些自己的數(shù)據(jù)上報(bào)操作
- return oldXHROpen.apply(this, arguments);
- }
- const oldXHRSend = XMLHttpRequest.prototype.send;
- XMLHttpRequest.prototype.send = (body) => {
- // 做一些自己的數(shù)據(jù)上報(bào)操作
- return oldXHRSend.apply(this, arguments);
- }
- }
3.1.4 業(yè)務(wù)信息
每個(gè)產(chǎn)品都會(huì)有自己的業(yè)務(wù)信息，例如用戶在線時(shí)長(zhǎng)、pv、uv、用戶分布等，通過(guò)獲取這些業(yè)務(wù)信息才能更加清楚的了解目前產(chǎn)品的狀況，以便產(chǎn)品經(jīng)理更好的去規(guī)劃產(chǎn)品的未來(lái)方向。由于每個(gè)產(chǎn)品業(yè)務(wù)信息多種多樣，小伙伴本可以按照自己的需求進(jìn)行撰寫代碼，此處我就不再贅述。
3.2上報(bào)
對(duì)于上報(bào)的方式無(wú)外乎兩種：一種是Ajax的方式上報(bào);另一種是通過(guò)Image的形式進(jìn)行上報(bào)。目前很多大廠采用的上報(bào)方式均是通過(guò)一個(gè)1*1像素的的gif圖片進(jìn)行上報(bào)，既然人家都采用該種策略，那我們就來(lái)嘮一嘮下面兩個(gè)問(wèn)題。
- 為什么采用Image的方式上報(bào)?
沒(méi)有跨域問(wèn)題。因?yàn)閿?shù)據(jù)服務(wù)器和后端服務(wù)器大概率是不同的域名，若采用Ajax的方式進(jìn)行處理還要處理跨域問(wèn)題，否則數(shù)據(jù)會(huì)被瀏覽器攔截。
不會(huì)阻塞頁(yè)面加載，只需new Image對(duì)象即可。
- 圖片類型很多，為什么采用gif這種格式進(jìn)行上報(bào)?
其實(shí)歸結(jié)為一個(gè)字——小。對(duì)于1*1px的圖片，BMP結(jié)構(gòu)的文件需要74字節(jié)，PNG結(jié)構(gòu)的文件需要67字節(jié)，GIF結(jié)構(gòu)的文件只需要43字節(jié)。同樣的響應(yīng)，GIF可以比BMP節(jié)約41%的流量，比PNG節(jié)約35%的流量，所以選擇gif進(jìn)行上報(bào)。
3.3分析
日志上報(bào)之后需要進(jìn)行清洗，獲取自己所需要內(nèi)容，并將分析內(nèi)容進(jìn)行存儲(chǔ)。根據(jù)數(shù)據(jù)量的大小可分為兩種方式：?jiǎn)螜C(jī)和集群。
一、單機(jī)
訪問(wèn)量小、日志少的網(wǎng)站可以采用單機(jī)的方式對(duì)數(shù)據(jù)進(jìn)行分析，例如用node讀取日志文件，然后通過(guò)日志文件中獲取所需要的信息，最終將處理的信息存儲(chǔ)到數(shù)據(jù)庫(kù)中。
二、集群
很多產(chǎn)品的訪問(wèn)量很大，日志很多，此時(shí)就需要利用Hadoop進(jìn)行分布式處理，獲取最終處理結(jié)果，其處理流程圖如下所示：
根據(jù)自己的日志量級(jí)決定自己的分析方式，合適的就是最好的，不用一味追求最優(yōu)的、最先進(jìn)的處理方式。
3.4報(bào)警
當(dāng)異常類型超多一定閾值之后需要進(jìn)行報(bào)警通知，讓對(duì)應(yīng)的工作人員去處理問(wèn)題，及時(shí)止損。根據(jù)報(bào)警的級(jí)別不同，可以選擇不同的報(bào)警方式。
- 郵件——普通報(bào)警
- 短信——嚴(yán)重報(bào)警，已影響部分業(yè)務(wù)
- 電話——特別嚴(yán)重，例如系統(tǒng)已宕機(jī)
本文轉(zhuǎn)載自微信公眾號(hào)「 執(zhí)鳶者」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系 執(zhí)鳶者公眾號(hào)。
當(dāng)前文章：一文徹底搞懂前端監(jiān)控
文章來(lái)源：http://www.5511xx.com/article/djgoeoi.html
