實現一個前端監控系統，應該考慮什么？如何去實現？
一、為什么要做前端監控
- 更快地發現問題。
- 做產品決策依據。
- 提升前端開發的技術深度和廣度。
- 為業務擴展提供更多可能性。
二、前端數據分類
前端的數據其實有很多，從大眾普遍關注的 PV、UV、廣告點擊量，到客戶端的網絡環境、登陸狀態，再到瀏覽器、操作系統信息，最后到頁面性能、JS 異常，這些數據都可以在前端收集到。
2.1 訪問相關的數據
- PV/UV:最基礎的 PV(頁面訪問量)、UV(獨立訪問用戶數據量)。
- 頁面來源：頁面的 referer,可以定位頁面的入口。
- 操作系統：了解用戶的 OS 情況，幫助分析用戶群體的特征，特別是移動端、iOS 和 Android 的分布就更有意義了。
- 瀏覽器：可以統計到各種瀏覽器的占比，對于是否繼續兼容 IE6、新技術(HTML5、CSS3 等)的運用等調研提供參考價值。
- 分辨率：對頁面設計提供參考，特別是響應式設計。
- 登錄率：登陸用戶具有更高的分析價值，引導用戶登陸是非常重要的。
- 地域分布：訪問用戶在地理位置上的分布，可以針對不同地域做運營、活動等。
- 網絡類型：wifi/3G/2G，為產品是否需要適配不同網絡環境做決策。
- 訪問時段：掌握用戶訪問時間的分布，引導削峰填谷、節省帶寬。
- 停留時長：判斷頁面內容是否具有吸引力，對于需要長時間閱讀的頁面比較有意義。
- 到達深度：和停留時長類似，例如百度百科，用戶瀏覽時的頁面到達深度直接反映詞條的質量。
2.2 性能相關的數據
- 白屏時間：用戶從打開頁面開始到頁面開始有東西呈現為止，這過程中占用的時間就是白屏時間。
- 首屏時間：用戶瀏覽器首屏內所有內容都呈現出來所花費的時間。
- 用戶可選擇操作時間：用戶可以進行正常的點擊、輸入等操作。
- 頁面總下載時間：頁面所有資源都加載完成并呈現出來所花的時間，即頁面 onload 的時間。
- 自定義的時間點：對于開發人員來說，完全可以自定義一些時間點，例如：某個組件 init 完成的時間、某個重要模塊加載的時間等等。
2.3 點擊相關的數據
- 頁面總點擊量。
- 人均點擊量：對于導航類的網頁，這項指標是非常重要的。
- 流出 url：同樣，導航類的網頁，直接了解網頁導流的去向。
- 點擊時間：用戶的所有點擊行為，在時間上的分布，反映了用戶點擊操作的習慣。
- 首次點擊時間：同上，但是只統計用戶的第一次點擊，如果該時間偏大，是否就表明頁面很卡導致用戶長時間不能點擊呢?
- 點擊熱力圖：根據用戶點擊的位置，我們可以畫出整個頁面的點擊熱力圖，可以很直觀地了解到頁面的熱點區域。
2.4 異常相關的數據
這里的異常是指 JS 的異常，用戶的瀏覽器上報 JS 的 bug，這會極大地降低用戶體驗
- 異常的提示信息：這是識別一個異常的最重要依據，如：e.src 為空或不是對象
- JS 文件名。
- 異常所在行。
- 發生異常的瀏覽器。
- 堆棧信息：必要的時候需要函數調用的堆棧信息，但是注意堆棧信息可能會比較大，需要截取。
2.5 其它數據
除了上面提到的 4 類基本的數據統計需求，我們當然還可以根據實際情況來定義一些其他的統計需求，如用戶瀏覽器對 canvas 的支持程度， 再比如比較特殊的-用戶進行輪播圖翻頁的次數，這些數據統計需求都是前端能夠滿足的，每一項統計的結果都體現了前端數據的價值。
三、性能指標
- FP(First Paint)：首次繪制時間，包括了任何用戶自定義的背景繪制，它是首先將像素繪制到屏幕的時刻。
- FCP(First Content Paint)：首次內容繪制。瀏覽器將第一個 DOM 渲染到屏幕的時間，可能是文本、圖像、SVG 等。這其實就是白屏時間。
- FMP(First Meaningful Paint)：首次有意義繪制。頁面有意義的內容渲染的時間
- LCP(Largest Contentful Paint)。最大內容渲染。代表在 viewport 中最大的頁面元素加載的時間。
- DCL(DomContentLoaded)：DOM 加載完成。當 HTML 文檔被完全加載和解析完成之后，DOMContentLoaded 事件被觸發。無需等待樣式表，圖像和子框架的完成加載。
- L(onload)：當依賴的資源全部加載完畢之后才會觸發。
- TTI(Time to Interactive)：可交互時間。用于標記應用已進行視覺渲染并能可靠響應用戶輸入的時間點。
- FID(First Input Delay)：首次輸入延遲。用戶首次和頁面交互(單擊鏈接、點擊按鈕等)到頁面響應交互的時間。
四、前端監控目標(監控分類)
4.1 穩定性(stability)
- JS 錯誤，JS 執行錯誤或者 Promise 異常。
- 資源異常，script、link 等資源加載異常。
- 接口錯誤,ajax 或 fetch 請求接口異常。
- 白屏，頁面空白。
4.2 用戶體驗(experience)
- 加載時間，各個階段的加載時間。
- TTFB(Time To First Byte 。 首字節時間)。是指瀏覽器發起第一個請求到數據返回第一個字節所消耗的時間，這個時間包含了網絡請求時間、后端處理時間。
- FP(First Paint 首次繪制)。首次繪制包括了任何用戶自定義的背景繪制，它是將第一個像素點繪制到屏幕的時間。
- FCP(First Content Paint 首次內容繪制)。首次內容繪制是瀏覽器將第一個 DOM 渲染到屏幕的時間，可以是任何文本、圖像、SVG 等的時間。
- FMP(First Meaningful Paint 首次有意義繪制)。 首次有意義繪制是頁面可用性的量度標準。
- FID(First Input Delay 首次輸入延遲)。用戶首次和頁面交互到頁面響應交互的時間。
- 卡頓。 超過 50ms 的任務。
4.3 業務
- PV：page view 即頁面瀏覽量或點擊量。
- UV：指訪問某個站點的不同 IP 地址的人數。
- 頁面停留時間：用戶在每一個頁面的停留時間。
五、前端監控流程
- 數據埋點。
- 數據上報。
- 分析和計算，將采集到的數據進行加工總結。
- 可視化展示，將數據按照各種維度進行展示。
- 監控報警，發現問題后按一定的條件觸發報警。
六、常見的埋點方案
6.1 代碼埋點
代碼埋點，就是以嵌入代碼的形式進行埋點，比如要監控用戶的點擊事件，會選擇在用戶點擊時插入一段代碼，保存這個監聽行為或者直接將監聽行為 以某一種數據格式直接傳遞給服務器端。
優點是可以在任意時刻，精確的發送或保存所需要的數據信息。
缺點就是工作量大。
6.2 可視化埋點
通過可視化交互的手段，代替代碼埋點。
將業務代碼和埋點代碼分離，提供一個可視化交互的頁面，輸入為業務代碼，通過這個可視化系統，可以在業務代碼中自定義 的增加埋點事件等等。最后輸出的代碼耦合了業務代碼和埋點代碼。
可視化埋點其實是用系統來代替手工插入埋點代碼。
6.3 無痕埋點
前端的任意一個事件都被綁定一個標識，所有的事件都被記錄下來。
通過定期上傳記錄文件，配合文件解析，解析出來我們想要的數據，并生成可視化報告供專業人員分析。
無痕埋點的優點是采集全量數據，不會出現漏埋和誤埋等現象。
缺點是給數據傳輸和服務器增加壓力，也無法靈活定制數據結構。
七、編寫監控采集腳本
7.1 監控錯誤
- 錯誤分類JS 錯誤Promise 異常。
- 資源異常監聽 error。
7.2 數據結構設計
- jsError
let info = {
title: "前端監控系統", // 頁面標題
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", // 選擇器
};- 接口異常數據結構設置
let info = {
title: "前端監控系統", // 頁面標題
url: "http://localhost:8080", // 頁面url
timestamp: "1212121212121212", // 訪問時間戳
userAgent: "chrome", // 用戶瀏覽器類型
kind: "stability", // 大類
type: "xhr", // 小類
eventType: "load", // 事件類型
pathname: "/success",
status: "200-0k",
duration: "5", // 持續時間
response: "hahah", // 響應內容
params: "參數", // 參數
};- 白屏 screen 返回當前 window 的 screen 對象，返回當前渲染窗口中和屏幕有關的屬性innerWidth 只讀的 window 屬性。innerWidth 返回以像素為單位的窗口的內部寬度innerHeight 窗口的內部高度(布局視口)的高度layout_viewportelementsFromPoint 方法可以獲取到當前視口內指定坐標處，由里到外排列的所有元素。
let info = {
title: "前端監控系統",
url: "http://localhost:8080/",
timestamp: "1239404040404044",
userAgent: "chorme",
kind: "stability",
type: "blank",
emptyPoints: "0", // 空白點
screen: "2049 * 1152", // 分辨率
viewPoint: "2048 * 994", // 視口
selector: "HTML BODY #container", // 選擇器
};整體大致可以分四個階段：信息采集、存儲、分析、監控。
采集階段：收集異常日志，先在本地做一定的處理，采取一定的方案上報到服務器。
存儲階段：后端接收前端上報的異常日志，經過一定處理，按照一定的存儲方案存儲。
分析階段：分為機器自動分析和人工分析。機器自動分析，通過預設的條件和算法，對存儲的日志信息進行統計和篩選，發現問題，觸發報警。人工分析，通過提供一個可視化的數據面板，讓系統用戶可以看到具體的日志數據，根據信息，發現異常問題根源。
報警階段：分為告警和預警。告警按照一定的級別自動報警，通過設定的渠道，按照一定的觸發規則進行。預警則在異常發生前，提前預判，給出警告。
性能監控： 使用 Resource Timing API 和 Performance Timing API，可以計算許多重要的指標，比如頁面性能統計的起始點時間、首屏時間等。
異常監控： 前端捕獲異常分為全局捕獲和局部捕獲。局部捕獲作為補充，對某些特殊情況進行捕獲，但分散，不利于管理。所以，我會選擇全局捕獲的方式，即通過全局的接口，將捕獲代碼集中寫在一個地方。具體在實現項目中，我應該會采用 badjs-report，它重寫了 window.onerror 進行上報異常，無需編寫任何捕獲錯誤的代碼。
前端埋點： 埋點的方案有手動埋點，即在需要監控的地方插入監控邏輯，但是工作量可能會很大;還有無埋點，前端自動采集全部事件，上報埋點數據，但是缺點是服務器壓力會很大。我可能傾向于采用聲明式埋點，將埋點代碼和具體的業務邏輯解耦，只用關心需要埋點的控件，并且為這些控件聲明需要的埋點數據即可，主要是為了降低埋點的成本吧。在 dom 元素上增添埋點信息，比如:
// key表示埋點的唯一標識；act表示埋點方式
<button data-stat="{key:'buttonKey', act: 'click'}">埋點</button>
埋點
監控告警： 這里我認為最便捷、高效的方式，就是接入內部的告警組了吧，尤其是在阿里，似乎什么輪子都有，那可能需要考慮就是觸發告警的閾值和時機了。
性能：使用 Performance API，可以得到許多重要的指標，如頁面性能統計的起始點時間、首屏時間等。
報錯：使用 onerror 和 onunhandledrejection，甚至是 try catch。
操作行為：對事件觸發函數做 patch，或者添加特定的事件監聽。
PV/UV：利用瀏覽器存儲方法或 Cookie、IP 等儲存相應用戶信息，隨請求發送。
設備信息：獲取 navigator.userAgent。
PV、UV 屬于增長數字類型，可以用 Redis 等記錄，如果有需要，定時入庫。其他屬于大量文字信息，可以用成熟的消息隊列來消費。因為有大量寫，所以可以考慮做讀寫分離。
技術難點：
可能整個系統比較復雜的就是如何高效合理的進行監控數據上傳。除了異常報錯信息本身，還需要記錄用戶操作日志，如果任何日志都立即上報，這無異于自造的 DDOS 攻擊。那就需要考慮前端日志的存儲，日志如何上傳，上傳前如何整理日志等問題。
前端在收集的過程中可能會影響用戶體驗。
后端對于收到的日志要使用合適的工具進行收集，數據量大時選擇如何取舍。
可能會采取的方案:
- indexDB 存儲日志，因為容量大、異步!不用考慮阻塞頁面問題。
- 在一個 webworker 中對日志進行整理，比如對每一條日志打上標簽，進行分類等操作。
- 上報日志也在 webworker 中進行，可以按照重要緊急度區分，判斷是否延時或者立即上報。
