實現一個前端監控系統，應該考慮什么？如何去實現？

作者：小焱2018 2022-04-08 09:52:13

開發前端

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

一、為什么要做前端監控

更快地發現問題。
做產品決策依據。
提升前端開發的技術深度和廣度。
為業務擴展提供更多可能性。

二、前端數據分類

前端的數據其實有很多，從大眾普遍關注的 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 等記錄，如果有需要，定時入庫。其他屬于大量文字信息，可以用成熟的消息隊列來消費。因為有大量寫，所以可以考慮做讀寫分離。

技術難點：

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

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

可能會采取的方案:

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

責任編輯：武曉燕來源：今日頭條

前端監控系統