在剛開始學前端的時候，那時候開發的應用總是在用戶的設備中出現一些報錯，開發者只知道這個型號的設備出現這個問題，但對其他信息卻全然不知，比如說其他操作系統、其他設備型號、其他頁面會有這個報錯嗎，這個報錯出現的頻率又是多少。每次出問題只能等待用戶反饋，不能第一時間去解決問題，甚至用戶沒反饋的話永遠也無法發現某些報錯。

后來了解到前端監控這個東西，才知道原來可以這樣去監控用戶設備上的應用。“前端監控”不單單包括web性能和JS異常的監聽，還包括處理日志的平臺。下面就來總結一下打造一個完整的前端監控系統的過程。

了解業務需求

首先要了解自己所在的團隊或者公司的具體需求。

• 如果是一個小團隊，可能只需要簡單的幾個數據即可，業務也只有一兩種，這樣的話整個系統會簡單很多，不用劃分很多模塊

• 如果是中廠或者大廠，很多個前端部門都需要用到這個平臺，那么就需要劃分成很多模塊，而且需要很多通用的特性（比如說維度，下面會講到）

了解完這個產品覆蓋的范圍后，就要開始調查開發者們需要在用戶手機中需要收集的數據，根據這些字段設計日志的數據結構和數據庫的設計

這里提到的數據可以包含以下幾個點和無數小點

性能統計

基礎數值（首次渲染時間、白屏時間等）

可交互（首次加載時頁面卡頓、操作時的js加載情況等）

資源（包括資源大小和資源的加載時間）

異常統計

JS異常

ajax異常

資源文件

img

其中大點需要一開始就確定，大點下面的小點我把他成為分組，分組可以被每個業務方根據自己的業務自定義，這樣可以極大增加系統的靈活性。

確定日志格式

type：首先要有一個type字段區分日志的類型，value比如performance（性能統計），abnormal（異常統計），除了這兩種比較常見的type，自己也可以根據團隊或公司業務來拓展value。

module：然后我們需要根據module字段區分各業務方，如商業研發部、基礎架構部，考慮到部門的名字用英文表示太長且容易誤會，可以用數字（分為前標和后標）映射來表示，如"1_1"表示商業研發部，"1_2"表示商業技術研發部，"2_1"表示基礎架構部，按申請的部的順序順延，相同的大部門可以使用相同的“前標”，“后標”也可以表示不同的項目，這些都可以根據自己的部門自定義。

group：使用group表示分組，比如可以將一個項目中不同的落地頁分成不同的組，將一個落地頁中不同的組件分為不同組，還是根據自己的業務自行調整。

dim：即dimension維度，這個比較重要，簡單說就是將每個數據都分為多個模塊來統計，常見的dim如操作系統（Android or iOS）、瀏覽器類型、是否落地頁、網絡類型等等。

info：性能或異常的具體信息，一個“大點”中的info要求一樣，這樣方便統計，如異常統計的info可以分為“異常信息”、“異常時間”、“異常類型”、“具體的異常位置（行數）”。還包括一些諸如操作系統和瀏覽器類型的公共信息。

img

數據結構如下

{type:?String,module:?String,group:?String,dim:?{//?各個維度的信息},info:?{//?具體信息} }

打造日志接收平臺

• 接收日志的接口可以設置在前端監控平臺的server端，暴露一個接口即可，通過type來調用不同的處理函數。

• 可以同時接收get請求和post請求。

• 支持get請求主要是方便發送日志，只需要把日志信息轉為query放在url后面就可以發送，后面會出具體的教程。

• 支持post請求是因為可以支持sendBeacon的post請求，可以優先采用，該api可以在會話結束后發送打點日志，降低打點丟失率。

在發送和接收日志的時候有幾點要注意的

若此網站的用戶訪問量很大，頻繁地發送日志會造成server端的壓力很大，可以參考一下以下兩個解決方法。

• 前端發送日志時抽樣發送。

const?randomNum?=?Math.random(); if(randomNum?<?0.1)?{??//?設置10%的抽樣send()??//?發送日志 }

• 前端可以將數據臨時保存在Storage中并合并起來，隔一段時間發送一次日志（類似節流）。

受網絡和設備老化的影響，有一些數據并不能反映網站的性能，這時候可以過濾極值來保證數據的可靠性。

即使抽樣檢測，日志數據依舊十分龐大，server端可以暴露一個delete的接口，服務器自動刪除老數據。

監控平臺

監控平臺主要包括可視化和異常報警兩個方面。

img

可視化

我們收集數據的一大目的就是為了方便地觀察數據的趨勢變化，可以結合表格、柱狀圖、餅圖、折線圖來展示。通過選擇分組和維度、日期來觀察不同狀態下的數據。這點和普通的管理系統并無兩樣。

為了觀察數據隨時間的變化，我們可以以小時、天、周來定義時間顆粒度，設置一個對比模式來比較不同時間顆粒度的數據，包括環比和上升下降值。

自定義設置時間間隔區間，觀察指定區域內的數據。

異常報警

顧名思義，異常報警就是當項目中某些異常的數量跟用戶設置的模式一致時，就會自動觸發報警，異常報警可以從以下幾個方面考慮。

支持小時級、天級選項，在小時級里面支持前后小時、上一天和當前天的同一小時、上一周和當前周的同一小時內的數據的對比；在天級里面支持上一天和當前天、上一周的同一天和當前天的數據的對比。

數據對比時支持環比（百分比）、數量的增減，支持大于、大于等于、小于、小于等于等比較方式，可以根據部門的業務情況來定義。

可以設置當前報警人的手機號或郵箱，還可以設置郵箱組，觸發報警時發送短信或郵件。

暴露一個觸發報警的接口，服務器按時請求該接口。

img

維度

在前端監控系統中維度是一個重要的概念，而自定義維度更能體現系統的自由度，他可以針對不同的業務自定義一套專屬的維度劃分，并且可以通過比較不同的維度情況去理解項目。自定義維度可以讓這套系統覆蓋絕大部分的業務統計需求。

怎么設計維度

img

比如說B站的首頁，性能指標可以有“頂部banner的視頻加載時間”、“首屏加載時間”、“后端數據加載時間”，當我們查看這幾個指標時，我們可能想對比一下未登錄狀態和已登錄狀態的指標，又或者想區分一下進入點是哪里（是從搜索結果頁點進來的還是從其他地方進來），還可能想看一下有緩存狀態和無緩存狀態的指標區別。

這樣就確定了三個維度，登錄狀態、進入點、緩存狀態。

確定維度后就可以確定維度的取值，進入點可以取三個值：直接輸入url、搜索結果頁點進、其他，登錄狀態和緩存狀態都是兩個值，每個維度的每個取值可以組成一個組合，這樣的話總共有12種組合，也就是說可以看到這個頁面12種情況下的指標情況。如果你發現此頁面有一些性能問題，但是又排查不出來，可以試著嘗試不同的維度組合，最后發現在已登錄和未登錄兩種狀態之間的數值相差很大，那么就可以定點排查登錄模塊的問題。

但是維度的組合太多不一定是好事，比如12個組合，發送一次打點，數據庫就會存入12條數據，如果是小時級的一天就會存入12×24條數據，若是維度組合數太多，就會非常浪費數據庫資源，所以在自定義維度時需要按需設置。

img

所以避免打點的時候維度組合太多將系統搞崩潰，發送打點日志之前需要先配置維度信息，發送日志時會將維度和配置好的維度進行diff，如果有diff，則視為攻擊，放棄這個日志數據。

維度提取

像操作系統os、瀏覽器類型這種取值太多了，一般不會直接作為維度，但是像移動端的操作系統只有ios、Android、other就可以直接作為默認維度，在解析日志時可以自動解析出當前站點、移動os、cookie、http類型等數據，并與自定義的維度進行合并。

當我們用英文或者url等復雜的字符串來作為維度的取值時，那么長一串確實不太合適，我們可以在設置維度時增加正則匹配，比如針對url就默認匹配它的站點值當維度的取值，針對如os這種可能需要翻譯成英文的維度，可以定義一個map來將英文轉為中文顯示在可視化界面中。

如何快速打點

關于快速打點，內容有點多，之后會再出一篇文章詳細介紹。

總結

看完這篇文章，相信你心里對前端監控系統的搭建也有自己的理解，希望能給你帶來一些啟示。

此文章只是簡單地概括一下搭建前端監控系統的步驟，并不涉及具體的代碼，更多具體的解決方案未來會在更多文章中體現，可以關注一下呀！

原文鏈接：https://juejin.cn/post/7151590970889338893，歡迎關注掘金賬號~！

往期回顧

#

如何使用 TypeScript 開發 React 函數式組件？

#

11 個需要避免的 React 錯誤用法

#

6 個 Vue3 開發必備的 VSCode 插件

#

3 款非常實用的 Node.js 版本管理工具

#

6 個你必須明白 Vue3 的 ref 和 reactive 問題

#

6 個意想不到的 JavaScript 問題

#

試著換個角度理解低代碼平臺設計的本質

總結

以上是生活随笔為你收集整理的【Web技术】1480- 呀！原来这就是前端监控系统的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。