前端線上監控體系設計

爲何

線上監控可讓咱們方便的瞭解到業務產品的真實指標，如訪問量、用戶交互數據、頁面錯誤、性能等關鍵信息。對於應用的體驗優化和用戶精細化運營相當重要。

線上監控是個比較複雜的體系，包括數據採集、處理計算、可視化等方面。這裏篇幅和知識所限，只說端上的數據採集方面。

作什麼

咱們已經瞭解到監控的所須要的數據指標，基於此咱們要採集哪些類型的數據呢？

具體以下：

• 應用加載、卸載，這是訪問量
• 路由切換，對於單頁面很重要
• 性能，包括加載時，運行時
• 錯誤，接口錯誤，JS 錯誤
• 用戶交互數據，點擊、眼球曝光埋點

不作什麼

咱們整個線上監控體系設計的目標是穩定（不會影響正常業務，埋點不會輕易失效），高效（不會對應用產生性能負擔），無侵入性（不會限制業務）。基於此咱們放棄如下方案。

不作無埋點/可視化埋點

無埋點和可視化埋點的原理都是利用 DOM 屬性或 css 選擇器將埋點和元素一一對應。而頁面結構變更反過來會影響埋點的定位。這也是它們不穩定的根本緣由。拋棄這類方案的緣由在於：它提供的收益（埋點開發效率）和成本（埋點失效後的排查、反饋、修復）不成正比。

數據模型

咱們如今已經知道了線上監控所關心的具體指標和數據類型，那麼具體到某一條數據，咱們關係哪些參數、用一個什麼樣的數據模型來指導咱們的採集和分析呢？

總的來看，咱們關注這些數據：

• 用戶是誰 用戶的設備ID，帳號
• 用戶的設備信息，什麼系統，什麼瀏覽器，4G 仍是 WIFI
• 時間信息，錯誤，用戶交互產生的時間
• 用戶產生了什麼行爲，點擊，眼球曝光，頁面切換
• 其餘上下文信息，IP，業務自定義數據

採集原理

應用加載卸載

固然是監聽 load 、beforeunload 事件

路由切換

固然能夠使用 hashchange 、hack history API，但這些很難獲取到動態路由的信息。好比若是一個路由的 path 爲 blog/:id。就很難將 blog/a 和 blog/b 作數據聚合。這方面能夠提供一個 sendPageView 方法給到業務，業務本身在路由鉤子內調用該方法便可。

性能數據

使用 performance API，具體不在贅述。

錯誤信息

能夠使用 window.onerror 來監聽一部分錯誤，但這個方法兼聽不到 promise 錯誤和 script error 。一些前端框架的錯誤，如 react 的 componentDidCatch 也須要作特殊定製。

用戶交互數據

用戶交互數據也就是一般所說的埋點，實現起來其實很是簡單。

好比咱們經過聲明式埋點來上報數據，埋點標識爲屬性中帶 data-track-id 的元素。

document.addEventListener('click', (e) => {
    if (e.path.some(el => el.matches('[data-track-id]'))) {
    // 上報數據
    }
}, true)
複製代碼

數據上報

以前也說到，監控方案的目標是穩定和高效。爲了避免影響業務應用的性能，咱們會把採集的關鍵邏輯使用 window.requestIdleCallback 包裹起來。

爲了在瀏覽器關閉時也能上報數據，咱們會使用 Navigator.sendBeacon 來上報數據，對於不支持這個 API 的瀏覽器，咱們使用構造 image 請求來作 fallback 和跨域。

爲了減小流量和服務器壓力，在採集端也會作緩存，請求協議上也會作一些優化，這裏再也不贅述。

總結

這裏簡單介紹了一些前端監控體系的方向和經驗之談。沒有涉及大數據處理，也不包括數據的聚合展現，數據採集只是這個體系中很小的一環。而線上監控其實也只是整個前端工程體系中的一小部分。做爲一個前端工程師，若是不懂運維，不懂後端，那麼能在整個前端工程體系中發揮的做用就頗有限。