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

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

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

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

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

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

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

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

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

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

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

這里的異常是指 JS 的異常，用戶的瀏覽器上報 JS 的 bug，這會極大地降低用戶體驗

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

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

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

三、性能指標(biāo)

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

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

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

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

4.2 用戶體驗(experience)

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

4.3 業(yè)務(wù)

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

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

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

六、常見的埋點方案

6.1 代碼埋點

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

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

缺點就是工作量大。

6.2 可視化埋點

通過可視化交互的手段，代替代碼埋點。

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

可視化埋點其實是用系統(tǒng)來代替手工插入埋點代碼。

6.3 無痕埋點

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

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

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

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

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

7.1 監(jiān)控錯誤

• 錯誤分類JS 錯誤Promise 異常。
• 資源異常監(jiān)聽 error。

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

• jsError

let info = {
  title: "前端監(jiān)控系統(tǒng)", // 頁面標(biāo)題
  url: "http://localhost:8080", // 頁面url
  timestamp: "1212121212121212", // 訪問時間戳
  userAgent: "chrome", // 用戶瀏覽器類型
  kind: "stability", // 大類
  type: "error", // 小類
  errorType: "jsError", // 錯誤類型
  message: "uncaught TypeError:blablabla", // 錯誤詳情
  filename: "http://localhost:8080/", // 訪問的文件名
  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)", // 頁面標(biāo)題
  url: "http://localhost:8080", // 頁面url
  timestamp: "1212121212121212", // 訪問時間戳
  userAgent: "chrome", // 用戶瀏覽器類型
  kind: "stability", // 大類
  type: "xhr", // 小類
  eventType: "load", // 事件類型
  pathname: "/success",
  status: "200-0k",
  duration: "5", // 持續(xù)時間
  response: "hahah", // 響應(yīng)內(nèi)容
  params: "參數(shù)", // 參數(shù)
};

• 白屏 screen 返回當(dāng)前 window 的 screen 對象，返回當(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", // 空白點
  screen: "2049 * 1152", // 分辨率
  viewPoint: "2048 * 994", // 視口
  selector: "HTML BODY #container", // 選擇器
};

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

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

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

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

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

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

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

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

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

埋點

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

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

報錯：使用 onerror 和 onunhandledrejection，甚至是 try catch。

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

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

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

PV、UV 屬于增長數(shù)字類型，可以用 Redis 等記錄，如果有需要，定時入庫。其他屬于大量文字信息，可以用成熟的消息隊列來消費。因為有大量寫，所以可以考慮做讀寫分離。

技術(shù)難點：

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

前端在收集的過程中可能會影響用戶體驗。

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

可能會采取的方案:

• indexDB 存儲日志，因為容量大、異步!不用考慮阻塞頁面問題。
• 在一個 webworker 中對日志進行整理，比如對每一條日志打上標(biāo)簽，進行分類等操作。
• 上報日志也在 webworker 中進行，可以按照重要緊急度區(qū)分，判斷是否延時或者立即上報。