前端監控與埋點

時間 2019-12-07

標籤前端監控简体版

原文原文鏈接

前端小兵，不吝賜教

背景

在線上項目中，咱們須要統計下用戶在使用該產品的行爲與使用狀況，經過這些統計數據進行處理與分析，從用戶的角度去了解該產品的使用與體驗，從而更好的進行產品的迭代與升級，更加符合用戶的體驗，更加貼近用戶使用習慣。所以，咱們在業務中須要添加一些用戶行爲統計的需求，如：前端

收集用戶在頁面的瀏覽量或點擊量
訪問某個站點不一樣 IP 的人數
用戶在頁面中停留的時間
用戶在頁面中觸發的行爲
用戶滾屏行爲

這些都是用戶數據的統計點，這也是前端數據監控的着重點。除了數據監控，前端監測還包括了性能監控和異常監控。性能監控有如下：git

首屏加載時間
白屏加載時間
http 響應時間
資源下載總體時間
頁面渲染時間
頁面交互動畫完成時間

異常監控包括了：監控腳本異常與樣式異常。github

爲何須要前端監控

埋點就是用戶數據的採集，獲取用戶行爲以及跟蹤產品用戶體驗狀況。埋點後，將收集到的用戶數據進行監控及處理，並以之爲基礎，指明產品優化的方向，是產品需求的來源，檢驗功能是否達到預期的佐證。數據採集與上報是整個流程中的重要一環，只有確保前端數據生產的全面、準確、及時，最終的數據結果纔是可靠的、有價值的。typescript

前端監控分爲三種：數據監控、性能監控、異常監控。以下圖所示：瀏覽器

數據監控能夠知道用戶的來源，能夠促進產品的推廣，知道用戶在頁面中停留的時間，能夠針對停留較長時間的頁面進行廣告推送等，增長推廣源。服務器

性能監控可讓開發人員更好的對產品進行有效的優化操做，加強用戶體驗。cookie

異常監控能夠及時上報異常狀況，能夠避免線上故障的發生與減小故障帶來的損失。網絡

常見工做流程以下：app

前端數據採集

前端數據採集也就是前端埋點和上報，前端埋點方法有三種：代碼埋點，可視化埋點和無痕埋點。埋點的技術實質，是先監聽軟件應用運行過程當中的事件，當須要關注的事件發生時進行判斷和捕獲。cors

代碼埋點

代碼埋點就是以嵌入代碼的形式進行埋點，例如用戶經過點擊事件觸發某個接口調用，咱們就能夠在點擊調用的接口中，插入一段代碼或者傳入某些參數，將數據直接傳遞給服務端。如：

在用戶登陸應用時，能夠將用戶信息傳送到服務器，統計該用戶的登陸次數，或者其餘信息。
在用戶點擊跳轉某個頁面時，能夠將 from, to 路由地址傳輸給服務器進行統計，能夠清楚知道用戶的訪問軌跡

優勢：能夠在任意時刻，精確的發送或保存所須要的數據信息。

缺點：工做量大，每一個組件的埋點代碼都須要相對應的添加。

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

可視化埋點

經過可視化工具配置採集節點，在前端自動解析配置並上報埋點數據，從而實現所謂的「無痕埋點」，表明方案是已經開源的 Mixpanel，能夠從這篇文章瞭解 Mixpanel 的使用。

優勢：埋點只需業務同窗接入監控，無需在開發中插入代碼。

缺點：可配置組件有限，不能手動定製，只有可視化工具提供。

無埋點

無埋點不是說不須要埋點，而是全部的前端事件都被綁定一個標識，經過這個標識把全部有關的事件都記錄下來，不須要開發人員添加額外代碼。經過定義上傳記錄文件，配合解析文件，將數據變成咱們想要的數據，並由數據分析人員進行分析實現無埋點統計，表明方案是國內的 GrowingIO。 GrowingIO 並非免費的，在開發測試能夠有一個免費的帳號使用，若是項目正式上線後就須要收費了。

優勢：無需開發，業務人員埋點便可；先上報，後埋點。

缺點：sdk 開發人員需提供一套無痕埋點技術成品，包括能正確獲取 PV，UV，Action，Time 等多項統計指標。前期技術投入大。

無埋點和可視化埋點均不須要開發支持，僅數據業務同窗進行設置便可。但二者數據上報-埋點設置存在較大的差別：無埋點支持在數據上報以後再進行埋點設置，於是數據採集與上報的量遠遠大於可視化埋點。

什麼時候進行監控

介紹了上面三種埋點方式，那咱們在產品項目中如何去運用呢？何時進行埋點，什麼地方進行監控呢？

其實監控時間分爲三部分：

用戶進入應用初始化
用戶在應用中的交互與交互後的響應
用戶在應用中所觸發捕獲的錯誤

如何設計監控

如何設計咱們產品所須要監控的數據? 咱們須要考慮 Web 端真實用戶體驗數據，從訪問速度、頁面運行穩定性和服務調用成功率三個方面監控前端的健康度，來不斷的升級迭代咱們的產品。

可經過如下幾個方面進行細分：

頁面性能日誌：網絡請求耗時、DOM 解析耗時、資源加載耗時、白屏時間、頁面徹底加載時間等...
訪問統計日誌：統計 PV、UV 數據
頁面穩定性日誌：監控頁面腳本的錯誤率來衡量頁面的穩定性
接口調用日誌：提供接口調用結果及耗時等相關信息，可讓開發人員快速發現並定位出錯的問題
自定義上報日誌

如何優化監控數據的上報

在添加完監控數據後，可能會增長接口請求或者頁面渲染的壓力，這時咱們就須要優化咱們的前端監控代碼或者請求的接口。

HTTP No Content

有的日誌上報只關心日誌是否有上報，而不關心上報的數據，如：監控用戶點擊某個按鈕觸發次數，這個咱們只要上報服務器一個事件便可，徹底不須要有返回內容。因此咱們使用 HTTP HEAD 上報的方式，能夠避免響應體響應數據而形成的資源損耗，只要有一個請求狀態碼記錄就能夠。

fetch(`${url}?t=click&page=foo&target=btn`, {
  mode: "no-cors",
  method: "HEAD",
});
複製代碼

HTTP 2.0

HTTP 2.0 頭部壓縮

每次的 HTPP 請求中都會攜帶一些相同的請求資源及特性，如 HOST、user-agent、Accept 等。這些數據佔用 300-800 byte 的傳輸量，若是還攜帶 cookie ，請求頭可能佔據 1 kb 的空間，而實際所須要上報的日誌數據僅佔 50 byte。在 HTTP 1.x 中，每第二天志上報請求頭都攜帶了大量的重複數據致使性能浪費。

而 HTTP/2 頭部壓縮採用 Huffman Code 壓縮請求頭，並用動態表更新每次請求不一樣的數據，從而將每次請求的頭部壓縮到很小。