第五期 | 前端監控怎麼玩？

2020.4.25 前端如何搞監控

場景

搭建平臺開發的組件太多，實際上不少功能相似，須要監控組件在一類場景下效能如何
組件監控的指標

• 引用量，引用次數高對此組件的優先級也高
• 曝光點擊率： 引導轉化率 = 引導成交量/點擊量/曝光量
• 數據接口： 加載時間、組件異常、白屏率
• 配置複雜度：好比輸入轉選擇類型，預設默認值，減小用戶配置時間
• 代碼質量：編譯過程當中，ESlint上報不合規

App、小程序監控
監控目的：

• 有沒有人用
• 用的怎麼樣
• 有什麼異常
• 如何跟蹤
• 分析解決
• 提供決策

工具
以宋小菜爲例：
----
初版

• Countly: 針對RN應用
• 友盟：針對原生APP

第二版

• BugSneg 針對RN
• MongoDB 數據存儲
• RGB 基於Koa自建

第三版

• 採集SDK 自研平臺
• Filebeat 節點 Node Transfer 作日誌採集轉發
• Kafka集羣作分佈式消息通訊
• ES(ElasticSearch) 日誌處理
• Datawarehouse 下沉到數倉
• Reports 大表哥報表平臺
• MySQL/Redis Task存儲

系統架構
----
客戶端： PC/H五、RN、小程序
日誌處理： log-transfer、Filebeat、Kafka集羣、ElasticSearch
數據處理： Data Warehouse、監控系統後臺
數據展示：可視化報表平臺、監控看板

爲何本身研發

以貝貝舉例：
假設有80個工程項目，每一年須要支付28W左右監控費用 > 本身研發成本
業界方案對比（有必定偏差，僅供參考）：

監控步驟

根據業務咱們能夠看到主要有兩種場景，

• 一種是用於廣告營銷類的，分析用戶行爲造成用戶畫像
• 另外一種主要是對本身系統作的錯誤監控，

這兩種場景的步驟也是不一樣的。

用戶監控： 埋點-> 採集 -> 計算 -> 分析
錯誤監控：錯誤收集-> 錯誤上報 -> 數據清洗 -> 數據持久化 -> 平臺可視化、監控

錯誤監控實現層面來自貝貝的 Allen 講師已經講的很詳細了，我這裏用腦圖整理了一下。
Web端錯誤監控腦圖：

其餘端

上面這套閉環的Web端監控，在其餘端怎麼用？其實主要是在第一層應用接入去作文章。
思路： 差別化採集、格式化上報

錯誤捕獲以及代碼實現

JS端：
錯誤捕獲： ErrorUtils、Promise.rejection Tracking
網絡請求： 替換XMLHttpRequest, 代理 send/open/onload 等方法

Native端：


微信小程序：
網絡請求：代理全局wx的wx.request對象

代碼實現：

React 端：

爲何選擇ES和Mysql?
存儲介質對比：


接下來是對營銷、廣告場景的監控分析：

埋點

監測用戶行爲、事件、留存 -> 上報數據，能夠分紅下面幾個級別：

• 站點級別
• 頁面級別
• 組件級別
• 組件內部連接級別

採集

採集哪些數據

• 用戶行爲數據： 用戶頁面操做、頁面跳轉、窗口事件
• 錯誤數據： 後端接口、前端JS錯誤 AppNative錯誤

經過單個頁面咱們能夠得到的一些結論：

• 用戶地域分佈
• 在線時長
• 按鈕點擊率
• 頁面來源分佈：內鏈、外鏈、搜索引擎
• 廣告位點擊率：點擊次數/曝光次數
• 日訪問量趨勢

如何採集用戶停留時間？

1. 使用置信區間，過濾異常數據。以下圖能夠看到有些平均時長不是很能表現用戶停留時間，採用中位數效果會好些

2. 採用柱狀圖展現用戶停留時長

怎麼採集事件？
鼠標、滾動、鍵盤、自定義事件
具體實現：

• sendBeacon方法 確保事件被髮送
• 兼容IE用戶， 發送請求
• CORS 發送post請求批量上報

怎麼將採集到的數據轉換爲人能夠理解的指標？
流程：搭建指標體系 -> 獲取數據 -> 數據分析 -> 具體到應用場景

舉例1：用戶登陸或者遊客訪問

三個框對應 瀏覽器數據、事件數據、用戶數據，自動生成uuid,和userid關聯，將 uuid 和 userid 存儲到cookie

舉例2：用戶跳轉

跳轉時記錄來源， 項目ID、頁面ID、區塊ID、坑位下標、串聯ID，
在下個頁面，從URL獲取utm值。而後進行頁面上報

計算

數據清洗案例：

分析

怎麼分析？
針對用戶採集能夠採用阿里雲 Log Service，主要功能是查詢和統計

分析什麼？


如何分析基礎數據 PV、UV、點擊數、曝光數
使用漏斗模型，分析轉化率 
用熱力圖分析頁面
經過漏斗和路徑分析來分析轉化率

遇到的坑

iOS符號化

符號化後去除了大量版本間的差別，對錯誤聚合提供了方便

錯誤聚合

初級聚合： 全內容散列，聚合度低

將錯誤直接MD5散列， 這樣聚合度會比較低，
通用優化：

• 同一類錯誤 錯誤名和錯誤堆棧是相同的
• 系統類行號去除，減小不一樣系統版本致使的堆棧不一致（用正則找到系統類，而後去掉行號）

而後對這些信息進行散列

針對優化：
同一類錯誤，有時候客戶端不一樣系統版本之間的系統
解決： 抽取業務代碼堆棧和業務名稱來散列
OOM錯誤，堆棧溢出
這一類錯誤，直接拿到錯誤名聚合，而後分析在哪些設備上容易出現

向ES中寫入 JSON 類型數據

數據量較大，全部數據並不是寫在一個索引中，這個時候須要按時或按天創建索引保存數據
同時，須要創建一個固定的索引模版，索引某一字段的數據類型必定要統一，不然會形成數據保存失敗的狀況。

字段問題：
哪些字段不變，哪些字段動態會變化的，須要設計系統時進行衡量，保持適度的靈活。
變化的字段集中在 pyload 信息，其餘類型字段都是固定的，好比：

• 設備特徵：如系統類型、版本
• 用戶特徵：如userId, ip、用戶所在地
• SDK信息:SDK類型、版本等

字段字符化處理：
若是使用JSON類型進行上報 且在ES中依然保存爲JSON數據，雖然存在索引模版，但在模版沒有照顧到的字段上報上來會生成新字段，於是形成字段數量爆炸、這時候就可使用log-transfer 

第三方推薦

• 友盟
• 數極客
• 神策
• GrowingIO
• Fundebug
• FrontJS
• Sentry

......

回顧

因爲後面還有事情，因此今天的活動沒有聽完，只對我聽過的一些進行了整理。
從業務上來看，監控的場景分爲錯誤監控和用戶行爲監控，固然還有阿里更復雜的組件級別、場景級別的監控（目前遇不到）。同時學習了一些監控實現的步驟、像埋點、採集。清洗、分析以前都是沒有接觸過的。
貝貝的兩位講師內容很接近落地方案，後續PPT還得多看看，若是有這方面的需求也會更多的去了解。

關於前端早早聊大會：前端早早聊大會目標成爲用得上、聽得懂、抄得走的技術大會，計劃 2020 年辦 >= 15 期，由前端早早聊與掘金聯合舉辦，前端早早聊大會行程動態、錄播視頻/PPT/講稿資料下載請關注 「前端早早聊」 公衆號跟進。

5 月 16 日舉辦第六屆 - 前端到底怎麼玩 Serverless(Paas|Faas)，報名請戳：huodongxing.com/go/tl6，海報及講師行程以下：

看完如有啓發，給做者點個👍吧