一、為什么要做前端監(jiān)控

• 更快地發(fā)現(xiàn)問(wèn)題。
• 做產(chǎn)品決策依據(jù)。
• 提升前端開(kāi)發(fā)的技術(shù)深度和廣度。
• 為業(yè)務(wù)擴(kuò)展提供更多可能性。

二、前端數(shù)據(jù)分類(lèi)

前端的數(shù)據(jù)其實(shí)有很多，從大眾普遍關(guān)注的 PV、UV、廣告點(diǎn)擊量，到客戶(hù)端的網(wǎng)絡(luò)環(huán)境、登陸狀態(tài)，再到瀏覽器、操作系統(tǒng)信息，最后到頁(yè)面性能、JS 異常，這些數(shù)據(jù)都可以在前端收集到。

2.1 訪問(wèn)相關(guān)的數(shù)據(jù)

• PV/UV:最基礎(chǔ)的 PV(頁(yè)面訪問(wèn)量)、UV(獨(dú)立訪問(wèn)用戶(hù)數(shù)據(jù)量)。
• 頁(yè)面來(lái)源：頁(yè)面的 referer,可以定位頁(yè)面的入口。
• 操作系統(tǒng)：了解用戶(hù)的 OS 情況，幫助分析用戶(hù)群體的特征，特別是移動(dòng)端、iOS 和 Android 的分布就更有意義了。
• 瀏覽器：可以統(tǒng)計(jì)到各種瀏覽器的占比，對(duì)于是否繼續(xù)兼容 IE6、新技術(shù)(HTML5、CSS3 等)的運(yùn)用等調(diào)研提供參考價(jià)值。
• 分辨率：對(duì)頁(yè)面設(shè)計(jì)提供參考，特別是響應(yīng)式設(shè)計(jì)。
• 登錄率：登陸用戶(hù)具有更高的分析價(jià)值，引導(dǎo)用戶(hù)登陸是非常重要的。
• 地域分布：訪問(wèn)用戶(hù)在地理位置上的分布，可以針對(duì)不同地域做運(yùn)營(yíng)、活動(dòng)等。
• 網(wǎng)絡(luò)類(lèi)型：wifi/3G/2G，為產(chǎn)品是否需要適配不同網(wǎng)絡(luò)環(huán)境做決策。
• 訪問(wèn)時(shí)段：掌握用戶(hù)訪問(wèn)時(shí)間的分布，引導(dǎo)削峰填谷、節(jié)省帶寬。
• 停留時(shí)長(zhǎng)：判斷頁(yè)面內(nèi)容是否具有吸引力，對(duì)于需要長(zhǎng)時(shí)間閱讀的頁(yè)面比較有意義。
• 到達(dá)深度：和停留時(shí)長(zhǎng)類(lèi)似，例如百度百科，用戶(hù)瀏覽時(shí)的頁(yè)面到達(dá)深度直接反映詞條的質(zhì)量。

2.2 性能相關(guān)的數(shù)據(jù)

• 白屏?xí)r間：用戶(hù)從打開(kāi)頁(yè)面開(kāi)始到頁(yè)面開(kāi)始有東西呈現(xiàn)為止，這過(guò)程中占用的時(shí)間就是白屏?xí)r間。
• 首屏?xí)r間：用戶(hù)瀏覽器首屏內(nèi)所有內(nèi)容都呈現(xiàn)出來(lái)所花費(fèi)的時(shí)間。
• 用戶(hù)可選擇操作時(shí)間：用戶(hù)可以進(jìn)行正常的點(diǎn)擊、輸入等操作。
• 頁(yè)面總下載時(shí)間：頁(yè)面所有資源都加載完成并呈現(xiàn)出來(lái)所花的時(shí)間，即頁(yè)面 onload 的時(shí)間。
• 自定義的時(shí)間點(diǎn)：對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)，完全可以自定義一些時(shí)間點(diǎn)，例如：某個(gè)組件 init 完成的時(shí)間、某個(gè)重要模塊加載的時(shí)間等等。

2.3 點(diǎn)擊相關(guān)的數(shù)據(jù)

• 頁(yè)面總點(diǎn)擊量。
• 人均點(diǎn)擊量：對(duì)于導(dǎo)航類(lèi)的網(wǎng)頁(yè)，這項(xiàng)指標(biāo)是非常重要的。
• 流出 url：同樣，導(dǎo)航類(lèi)的網(wǎng)頁(yè)，直接了解網(wǎng)頁(yè)導(dǎo)流的去向。
• 點(diǎn)擊時(shí)間：用戶(hù)的所有點(diǎn)擊行為，在時(shí)間上的分布，反映了用戶(hù)點(diǎn)擊操作的習(xí)慣。
• 首次點(diǎn)擊時(shí)間：同上，但是只統(tǒng)計(jì)用戶(hù)的第一次點(diǎn)擊，如果該時(shí)間偏大，是否就表明頁(yè)面很卡導(dǎo)致用戶(hù)長(zhǎng)時(shí)間不能點(diǎn)擊呢?
• 點(diǎn)擊熱力圖：根據(jù)用戶(hù)點(diǎn)擊的位置，我們可以畫(huà)出整個(gè)頁(yè)面的點(diǎn)擊熱力圖，可以很直觀地了解到頁(yè)面的熱點(diǎn)區(qū)域。

2.4 異常相關(guān)的數(shù)據(jù)

這里的異常是指 JS 的異常，用戶(hù)的瀏覽器上報(bào) JS 的 bug，這會(huì)極大地降低用戶(hù)體驗(yàn)

• 異常的提示信息：這是識(shí)別一個(gè)異常的最重要依據(jù)，如：e.src 為空或不是對(duì)象
• JS 文件名。
• 異常所在行。
• 發(fā)生異常的瀏覽器。
• 堆棧信息：必要的時(shí)候需要函數(shù)調(diào)用的堆棧信息，但是注意堆棧信息可能會(huì)比較大，需要截取。

2.5 其它數(shù)據(jù)

除了上面提到的 4 類(lèi)基本的數(shù)據(jù)統(tǒng)計(jì)需求，我們當(dāng)然還可以根據(jù)實(shí)際情況來(lái)定義一些其他的統(tǒng)計(jì)需求，如用戶(hù)瀏覽器對(duì) canvas 的支持程度， 再比如比較特殊的-用戶(hù)進(jìn)行輪播圖翻頁(yè)的次數(shù)，這些數(shù)據(jù)統(tǒng)計(jì)需求都是前端能夠滿(mǎn)足的，每一項(xiàng)統(tǒng)計(jì)的結(jié)果都體現(xiàn)了前端數(shù)據(jù)的價(jià)值。

三、性能指標(biāo)

• FP(First Paint)：首次繪制時(shí)間，包括了任何用戶(hù)自定義的背景繪制，它是首先將像素繪制到屏幕的時(shí)刻。
• FCP(First Content Paint)：首次內(nèi)容繪制。瀏覽器將第一個(gè) DOM 渲染到屏幕的時(shí)間，可能是文本、圖像、SVG 等。這其實(shí)就是白屏?xí)r間。
• FMP(First Meaningful Paint)：首次有意義繪制。頁(yè)面有意義的內(nèi)容渲染的時(shí)間
• LCP(Largest Contentful Paint)。最大內(nèi)容渲染。代表在 viewport 中最大的頁(yè)面元素加載的時(shí)間。
• DCL(DomContentLoaded)：DOM 加載完成。當(dāng) HTML 文檔被完全加載和解析完成之后，DOMContentLoaded 事件被觸發(fā)。無(wú)需等待樣式表，圖像和子框架的完成加載。
• L(onload)：當(dāng)依賴(lài)的資源全部加載完畢之后才會(huì)觸發(fā)。
• TTI(Time to Interactive)：可交互時(shí)間。用于標(biāo)記應(yīng)用已進(jìn)行視覺(jué)渲染并能可靠響應(yīng)用戶(hù)輸入的時(shí)間點(diǎn)。
• FID(First Input Delay)：首次輸入延遲。用戶(hù)首次和頁(yè)面交互(單擊鏈接、點(diǎn)擊按鈕等)到頁(yè)面響應(yīng)交互的時(shí)間。

四、前端監(jiān)控目標(biāo)(監(jiān)控分類(lèi))

4.1 穩(wěn)定性(stability)

• JS 錯(cuò)誤，JS 執(zhí)行錯(cuò)誤或者 Promise 異常。
• 資源異常，script、link 等資源加載異常。
• 接口錯(cuò)誤,ajax 或 fetch 請(qǐng)求接口異常。
• 白屏，頁(yè)面空白。

4.2 用戶(hù)體驗(yàn)(experience)

1. 加載時(shí)間，各個(gè)階段的加載時(shí)間。
2. TTFB(Time To First Byte 。 首字節(jié)時(shí)間)。是指瀏覽器發(fā)起第一個(gè)請(qǐng)求到數(shù)據(jù)返回第一個(gè)字節(jié)所消耗的時(shí)間，這個(gè)時(shí)間包含了網(wǎng)絡(luò)請(qǐng)求時(shí)間、后端處理時(shí)間。
3. FP(First Paint 首次繪制)。首次繪制包括了任何用戶(hù)自定義的背景繪制，它是將第一個(gè)像素點(diǎn)繪制到屏幕的時(shí)間。
4. FCP(First Content Paint 首次內(nèi)容繪制)。首次內(nèi)容繪制是瀏覽器將第一個(gè) DOM 渲染到屏幕的時(shí)間，可以是任何文本、圖像、SVG 等的時(shí)間。
5. FMP(First Meaningful Paint 首次有意義繪制)。 首次有意義繪制是頁(yè)面可用性的量度標(biāo)準(zhǔn)。
6. FID(First Input Delay 首次輸入延遲)。用戶(hù)首次和頁(yè)面交互到頁(yè)面響應(yīng)交互的時(shí)間。
7. 卡頓。 超過(guò) 50ms 的任務(wù)。

4.3 業(yè)務(wù)

• PV：page view 即頁(yè)面瀏覽量或點(diǎn)擊量。
• UV：指訪問(wèn)某個(gè)站點(diǎn)的不同 IP 地址的人數(shù)。
• 頁(yè)面停留時(shí)間：用戶(hù)在每一個(gè)頁(yè)面的停留時(shí)間。

五、前端監(jiān)控流程

• 數(shù)據(jù)埋點(diǎn)。
• 數(shù)據(jù)上報(bào)。
• 分析和計(jì)算，將采集到的數(shù)據(jù)進(jìn)行加工總結(jié)。
• 可視化展示，將數(shù)據(jù)按照各種維度進(jìn)行展示。
• 監(jiān)控報(bào)警，發(fā)現(xiàn)問(wèn)題后按一定的條件觸發(fā)報(bào)警。

六、常見(jiàn)的埋點(diǎn)方案

6.1 代碼埋點(diǎn)

代碼埋點(diǎn)，就是以嵌入代碼的形式進(jìn)行埋點(diǎn)，比如要監(jiān)控用戶(hù)的點(diǎn)擊事件，會(huì)選擇在用戶(hù)點(diǎn)擊時(shí)插入一段代碼，保存這個(gè)監(jiān)聽(tīng)行為或者直接將監(jiān)聽(tīng)行為 以某一種數(shù)據(jù)格式直接傳遞給服務(wù)器端。

優(yōu)點(diǎn)是可以在任意時(shí)刻，精確的發(fā)送或保存所需要的數(shù)據(jù)信息。

缺點(diǎn)就是工作量大。

6.2 可視化埋點(diǎn)

通過(guò)可視化交互的手段，代替代碼埋點(diǎn)。

將業(yè)務(wù)代碼和埋點(diǎn)代碼分離，提供一個(gè)可視化交互的頁(yè)面，輸入為業(yè)務(wù)代碼，通過(guò)這個(gè)可視化系統(tǒng)，可以在業(yè)務(wù)代碼中自定義 的增加埋點(diǎn)事件等等。最后輸出的代碼耦合了業(yè)務(wù)代碼和埋點(diǎn)代碼。

可視化埋點(diǎn)其實(shí)是用系統(tǒng)來(lái)代替手工插入埋點(diǎn)代碼。

6.3 無(wú)痕埋點(diǎn)

前端的任意一個(gè)事件都被綁定一個(gè)標(biāo)識(shí)，所有的事件都被記錄下來(lái)。

通過(guò)定期上傳記錄文件，配合文件解析，解析出來(lái)我們想要的數(shù)據(jù)，并生成可視化報(bào)告供專(zhuān)業(yè)人員分析。

無(wú)痕埋點(diǎn)的優(yōu)點(diǎn)是采集全量數(shù)據(jù)，不會(huì)出現(xiàn)漏埋和誤埋等現(xiàn)象。

缺點(diǎn)是給數(shù)據(jù)傳輸和服務(wù)器增加壓力，也無(wú)法靈活定制數(shù)據(jù)結(jié)構(gòu)。

七、編寫(xiě)監(jiān)控采集腳本

7.1 監(jiān)控錯(cuò)誤

• 錯(cuò)誤分類(lèi)JS 錯(cuò)誤Promise 異常。
• 資源異常監(jiān)聽(tīng) error。

7.2 數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)

• jsError

let info = {
  title: "前端監(jiān)控系統(tǒng)", // 頁(yè)面標(biāo)題
  url: "http://localhost:8080", // 頁(yè)面url
  timestamp: "1212121212121212", // 訪問(wèn)時(shí)間戳
  userAgent: "chrome", // 用戶(hù)瀏覽器類(lèi)型
  kind: "stability", // 大類(lèi)
  type: "error", // 小類(lèi)
  errorType: "jsError", // 錯(cuò)誤類(lèi)型
  message: "uncaught TypeError:blablabla", // 錯(cuò)誤詳情
  filename: "http://localhost:8080/", // 訪問(wèn)的文件名
  position: "0:0", // 行列信息
  stack: "btn Click (http://localhost:8080)", // 堆棧信息
  selector: "HTML BODY #container .content INPUT", // 選擇器
};

• 接口異常數(shù)據(jù)結(jié)構(gòu)設(shè)置

let info = {
  title: "前端監(jiān)控系統(tǒng)", // 頁(yè)面標(biāo)題
  url: "http://localhost:8080", // 頁(yè)面url
  timestamp: "1212121212121212", // 訪問(wèn)時(shí)間戳
  userAgent: "chrome", // 用戶(hù)瀏覽器類(lèi)型
  kind: "stability", // 大類(lèi)
  type: "xhr", // 小類(lèi)
  eventType: "load", // 事件類(lèi)型
  pathname: "/success",
  status: "200-0k",
  duration: "5", // 持續(xù)時(shí)間
  response: "hahah", // 響應(yīng)內(nèi)容
  params: "參數(shù)", // 參數(shù)
};

• 白屏 screen 返回當(dāng)前 window 的 screen 對(duì)象，返回當(dāng)前渲染窗口中和屏幕有關(guān)的屬性innerWidth 只讀的 window 屬性。innerWidth 返回以像素為單位的窗口的內(nèi)部寬度innerHeight 窗口的內(nèi)部高度(布局視口)的高度layout_viewportelementsFromPoint 方法可以獲取到當(dāng)前視口內(nèi)指定坐標(biāo)處，由里到外排列的所有元素。

let info = {
  title: "前端監(jiān)控系統(tǒng)",
  url: "http://localhost:8080/",
  timestamp: "1239404040404044",
  userAgent: "chorme",
  kind: "stability",
  type: "blank",
  emptyPoints: "0", // 空白點(diǎn)
  screen: "2049 * 1152", // 分辨率
  viewPoint: "2048 * 994", // 視口
  selector: "HTML BODY #container", // 選擇器
};

整體大致可以分四個(gè)階段：信息采集、存儲(chǔ)、分析、監(jiān)控。

采集階段：收集異常日志，先在本地做一定的處理，采取一定的方案上報(bào)到服務(wù)器。

存儲(chǔ)階段：后端接收前端上報(bào)的異常日志，經(jīng)過(guò)一定處理，按照一定的存儲(chǔ)方案存儲(chǔ)。

分析階段：分為機(jī)器自動(dòng)分析和人工分析。機(jī)器自動(dòng)分析，通過(guò)預(yù)設(shè)的條件和算法，對(duì)存儲(chǔ)的日志信息進(jìn)行統(tǒng)計(jì)和篩選，發(fā)現(xiàn)問(wèn)題，觸發(fā)報(bào)警。人工分析，通過(guò)提供一個(gè)可視化的數(shù)據(jù)面板，讓系統(tǒng)用戶(hù)可以看到具體的日志數(shù)據(jù)，根據(jù)信息，發(fā)現(xiàn)異常問(wèn)題根源。

報(bào)警階段：分為告警和預(yù)警。告警按照一定的級(jí)別自動(dòng)報(bào)警，通過(guò)設(shè)定的渠道，按照一定的觸發(fā)規(guī)則進(jìn)行。預(yù)警則在異常發(fā)生前，提前預(yù)判，給出警告。

性能監(jiān)控： 使用 Resource Timing API 和 Performance Timing API，可以計(jì)算許多重要的指標(biāo)，比如頁(yè)面性能統(tǒng)計(jì)的起始點(diǎn)時(shí)間、首屏?xí)r間等。

異常監(jiān)控： 前端捕獲異常分為全局捕獲和局部捕獲。局部捕獲作為補(bǔ)充，對(duì)某些特殊情況進(jìn)行捕獲，但分散，不利于管理。所以，我會(huì)選擇全局捕獲的方式，即通過(guò)全局的接口，將捕獲代碼集中寫(xiě)在一個(gè)地方。具體在實(shí)現(xiàn)項(xiàng)目中，我應(yīng)該會(huì)采用 badjs-report，它重寫(xiě)了 window.onerror 進(jìn)行上報(bào)異常，無(wú)需編寫(xiě)任何捕獲錯(cuò)誤的代碼。

前端埋點(diǎn)： 埋點(diǎn)的方案有手動(dòng)埋點(diǎn)，即在需要監(jiān)控的地方插入監(jiān)控邏輯，但是工作量可能會(huì)很大;還有無(wú)埋點(diǎn)，前端自動(dòng)采集全部事件，上報(bào)埋點(diǎn)數(shù)據(jù)，但是缺點(diǎn)是服務(wù)器壓力會(huì)很大。我可能傾向于采用聲明式埋點(diǎn)，將埋點(diǎn)代碼和具體的業(yè)務(wù)邏輯解耦，只用關(guān)心需要埋點(diǎn)的控件，并且為這些控件聲明需要的埋點(diǎn)數(shù)據(jù)即可，主要是為了降低埋點(diǎn)的成本吧。在 dom 元素上增添埋點(diǎn)信息，比如:

// key表示埋點(diǎn)的唯一標(biāo)識(shí)；act表示埋點(diǎn)方式
<button data-stat="{key:'buttonKey', act: 'click'}">埋點(diǎn)</button>

埋點(diǎn)

監(jiān)控告警： 這里我認(rèn)為最便捷、高效的方式，就是接入內(nèi)部的告警組了吧，尤其是在阿里，似乎什么輪子都有，那可能需要考慮就是觸發(fā)告警的閾值和時(shí)機(jī)了。

性能：使用 Performance API，可以得到許多重要的指標(biāo)，如頁(yè)面性能統(tǒng)計(jì)的起始點(diǎn)時(shí)間、首屏?xí)r間等。

報(bào)錯(cuò)：使用 onerror 和 onunhandledrejection，甚至是 try catch。

操作行為：對(duì)事件觸發(fā)函數(shù)做 patch，或者添加特定的事件監(jiān)聽(tīng)。

PV/UV：利用瀏覽器存儲(chǔ)方法或 Cookie、IP 等儲(chǔ)存相應(yīng)用戶(hù)信息，隨請(qǐng)求發(fā)送。

設(shè)備信息：獲取 navigator.userAgent。

PV、UV 屬于增長(zhǎng)數(shù)字類(lèi)型，可以用 Redis 等記錄，如果有需要，定時(shí)入庫(kù)。其他屬于大量文字信息，可以用成熟的消息隊(duì)列來(lái)消費(fèi)。因?yàn)橛写罅繉?xiě)，所以可以考慮做讀寫(xiě)分離。

技術(shù)難點(diǎn)：

可能整個(gè)系統(tǒng)比較復(fù)雜的就是如何高效合理的進(jìn)行監(jiān)控?cái)?shù)據(jù)上傳。除了異常報(bào)錯(cuò)信息本身，還需要記錄用戶(hù)操作日志，如果任何日志都立即上報(bào)，這無(wú)異于自造的 DDOS 攻擊。那就需要考慮前端日志的存儲(chǔ)，日志如何上傳，上傳前如何整理日志等問(wèn)題。

前端在收集的過(guò)程中可能會(huì)影響用戶(hù)體驗(yàn)。

后端對(duì)于收到的日志要使用合適的工具進(jìn)行收集，數(shù)據(jù)量大時(shí)選擇如何取舍。

可能會(huì)采取的方案:

• indexDB 存儲(chǔ)日志，因?yàn)槿萘看蟆惒?不用考慮阻塞頁(yè)面問(wèn)題。
• 在一個(gè) webworker 中對(duì)日志進(jìn)行整理，比如對(duì)每一條日志打上標(biāo)簽，進(jìn)行分類(lèi)等操作。
• 上報(bào)日志也在 webworker 中進(jìn)行，可以按照重要緊急度區(qū)分，判斷是否延時(shí)或者立即上報(bào)。