摘要：異常監控包括前端腳本執行報錯等。本文針對整個前端監控，設計適用的方案。前端埋點系統的前后端通信加密在上報數據的前后端通信中，需要和端協商加密機制，利用庫來實現的加密，已經是一個廣泛被采用的加密算法。

在線上項目中,需要統計產品中用戶行為和使用情況，從而可以從用戶和產品的角度去了解用戶群體，從而升級和迭代產品，使其更加貼近用戶。用戶行為數據可以通過前端數據監控的方式獲得，除此之外，前端還需要實現性能監控和異常監控。性能監控包括首屏加載時間、白屏時間、http請求時間和http響應時間。異常監控包括前端腳本執行報錯等。

實現前端監控有三個步驟：前端埋點和上報、數據處理和數據分析。本文針對整個前端監控，設計適用的方案。本文的主要內容分為：

為什么需要前端監控
常用前端埋點方案總結
前端埋點方案選型和前端上報方案設計
前端監控結果可視化展示系統的設計

原文的地址，在我的博客中：https://github.com/forthealll...

如有幫助，您的star是對我最好的鼓勵～

前端監控的目的是：

獲取用戶行為以及跟蹤產品在用戶端的使用情況，并以監控數據為基礎，指明產品優化的方向。

前端監控可以分為三類：數據監控、性能監控和異常監控。下面我們來一一的了解。

數據監控，顧名思義就是監聽用戶的行為。常見的數據監控包括：

PV/UV:PV(page view)，即頁面瀏覽量或點擊量。UV:指訪問某個站點或點擊某條新聞的不同IP地址的人數

用戶在每一個頁面的停留時間

用戶通過什么入口來訪問該網頁

用戶在相應的頁面中觸發的行為

統計這些數據是有意義的，比如我們知道了用戶來源的渠道，可以促進產品的推廣，知道用戶在每一個頁面停留的時間，可以針對停留較長的頁面，增加廣告推送等等。

性能監控指的是監聽前端的性能，主要包括監聽網頁或者說產品在用戶端的體驗。常見的性能監控數據包括：

不同用戶，不同機型和不同系統下的首屏加載時間

白屏時間

http等請求的響應時間

靜態資源整體下載時間

頁面渲染時間

頁面交互動畫完成時間

這些性能監控的結果，可以展示前端性能的好壞，根據性能監測的結果可以進一步的去優化前端性能，比如兼容低版本瀏覽器的動畫效果，加快首屏加載等等。

此外，產品的前端代碼在執行過程中也會發生異常，因此需要引入異常監控。及時的上報異常情況，可以避免線上故障的發上。雖然大部分異常可以通過try catch的方式捕獲，但是比如內存泄漏以及其他偶現的異常難以捕獲。常見的需要監控的異常包括：

Javascript的異常監控

樣式丟失的異常監控

在上一節中介紹了前端監控的作用，那么如何實現前端監控呢，實現前端監控的步驟為：前端埋點和上報、數據處理和數據分析。首要的步驟就是前端埋點和上報，也就是數據的收集階段。數據收集的豐富性和準確性會影響對產品線上效果的判別結果。

目前常見的前端埋點方法分為三種：代碼埋點、可視化埋點和無痕埋點。下面一一介紹每一種埋點的方法。

代碼埋點，就是以嵌入代碼的形式進行埋點，比如需要監控用戶的點擊事件，會選擇在用戶點擊時，插入一段代碼，保存這個監聽行為或者直接將監聽行為以某一種數據格式直接傳遞給server端。此外比如需要統計產品的PV和UV的時候，需要在網頁的初始化時，發送用戶的訪問信息等。

代碼埋點的優點：

可以在任意時刻，精確的發送或保存所需要的數據信息。

缺點：

工作量較大，每一個組件的埋點都需要添加相應的代碼

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

可視化埋點聽起來比較高大上，實際上跟代碼埋點還是區別不大。也就是用一個系統來實現手動插入代碼埋點的過程。

缺點：

可視化埋點可以埋點的控件有限，不能手動定制。

無埋點并不是說不需要埋點，而是全部埋點，前端的任意一個事件都被綁定一個標識，所有的事件都別記錄下來。通過定期上傳記錄文件，配合文件解析，解析出來我們想要的數據，并生成可視化報告供專業人員分析因此實現“無埋點”統計。

從語言層面實現無埋點也很簡單，比如從頁面的js代碼中，找出dom上被綁定的事件，然后進行全埋點。

無埋點的優點：

由于采集的是全量數據，所以產品迭代過程中是不需要關注埋點邏輯的，也不會出現漏埋、誤埋等現象

缺點：

無埋點采集全量數據，給數據傳輸和服務器增加壓力

無法靈活的定制各個事件所需要上傳的數據

第一章中介紹了前端所需要監聽的信息，在第二章中介紹了前端埋點的常見方式，本文來根據需求，來定制我們的埋點和上報方案。

首先我們需要明確一個產品或者網頁，普遍需要監控和上報的數據。監控的分為三個階段：用戶進入網頁首頁、用戶在網頁內部交互和交互中報錯。每一個階段需要監控和上報的數據如下圖所示：

在實際項目中考慮到上報數據的靈活定制，以及減少數據傳輸和服務器的壓力，在所需埋點處不多的情況下，常用的方式是代碼埋點。

以用戶進入首頁為例，我們在首頁渲染完成后會發送事件類型和類型相關的數據給server端，告知首頁的監控信息。

如果埋點的事件不是很多，上報可以時時進行，比如監控用戶的交互事件，可以在用戶觸發事件后，立刻上報用戶所觸發的事件類型。如果埋點的事件較多，或者說網頁內部交互頻繁，可以通過本地存儲的方式先緩存上報信息，然后定期上報。

接著來確定需要埋點上報的數據，上報的信息包括用戶個人信息以及用戶行為，主要數據可以分為：

who: appid(系統或者應用的id),userAgent(用戶的系統、網絡等信息)

when: timestamp(上報的時間戳)

from where: currentUrl(用戶當前url)，fromUrl(從哪一個頁面跳轉到當前頁面)，type(上報的事件類型),element(觸發上報事件的元素）

what: 上報的自定義擴展數據data:{},擴展數據中可以按需求定制，比如包含uid等信息

上報數據的對象為：

{   
    ----------------上報接口本身提供--------------------
    currentUrl,  
    fromUrl,
    timestamp,
    userAgent:{
       os,
       netWord,
    }
    ----------------業務代碼配置和自定義上報數據------------
    type,
    appid,
    element,
    data:{
        uid,
        uname
    }
}

我們以上報首屏加載事件為例，DOM提供了document的DOMContentLoaded事件來監聽dom掛載，提供了window的load事件來監聽頁面所有資源加載渲染完畢。

在上報數據的前后端通信中，需要和server端協商加密機制，利用 OpenSSL庫來實現的加密，OpenSSL已經是一個廣泛被采用的加密算法。前端可以采用node的crypto模塊。

首先來看hash算法，crypto.createHash() 來創建一個Hash實例，可利用的hash算法如下：

md5

sha1

sha256

sha512

ripemd160

以sha256算法加密為例：

const str="123445";//需要加密的字段
const hash=crypto.createHash("sha256");//指定加密算法
hash.update(str); //通過算法加密相應的字段
const result=hash.digest("hex");//轉化成十六進制

當后端得到前端上報的信息之后，經過數據分析和處理，需要前端可視化的展示數據分析后的結果。

可以在開源中后臺系統ant-design-pro的基礎上進行二次開發，首先要明確展示信息。展示的信息包括單個用戶和整體應用。

對于單個用戶來說需要展示的監控信息為：

單個用戶，在交互過程中觸發各個埋點事件的次數

單個用戶，在某個時間周期內，訪問本網頁的入口來源

單個用戶，在每一個子頁面的停留時間

對于全體用戶需要展示的信息為：

某一個時間段內網頁的PV和UV

全體用戶訪問網頁的設備和操作系統分析

某一個時間段內訪問本網頁的入口來源分析

全體用戶在訪問本網頁時，在交互過程中觸發各個埋點事件的總次數

全體用戶在訪問本網頁時，網頁上報異常的集合

刪選功能集合：

時間篩選：提供今日（00點到當前時間）、本周、本月和全年

用戶刪選：提供根據用戶id刪選出用戶行為的統計信息

設備刪選：刪選不同系統的整體展示信息