第五期|前端搞監控：開發的角度去理解監控和埋點，多端錯誤監控實現

自述

先說一下此次大會很長，我最後兩場沒聽了。不過比較勁爆的是知道了阿里的釘釘是用的c++的框架開發的。果真前端作客戶端方面仍是有所欠缺啊。前端

此次大會是8場，從早上10點到下午6點。分別有node

我我的聽的迷迷糊糊，其中我記得貝貝集團講的很是乾貨。幾乎是純技術角度分享了本身遇到的問題。我我的對此次大會主要是一個我的總結。mysql

記得比較慘痛的是公里網面試的時候問我埋點。唉，那會仍是太年輕react

這個大哥的文章很不錯，比我有看法：https://juejin.im/post/5ea4dc1ee51d4546c72e2eceios

1、爲何須要監控和埋點

首先爲何咱們須要埋點和監控？能帶來什麼好處？解決什麼業務痛點？c++

一、技術不難

首先我必須聲明一下，初級的監控這塊其實你們都會寫。說的簡單點，無非就是全局監控error和代碼侵入式的監控。因此從技術難點上，監控的技術難點不大。面試

二、請思考大家的業務

首先C端這塊其實在代碼監控上也許不是很是迫切，可是埋點應該是比較須要的。sql

好處：監控用戶行爲，進行數據分析，加速賣貨，引導客戶等等，等等數據庫

B端：對於用戶的行爲分析意義也許不大，可是B端更追求穩定，因此錯誤監控方面更加須要redux

這些都是我我的比較片面的一些理解

三、ppt實例參考

我的看法有限，我放點截圖讓你們發散下思惟

2、該如何設計監控，你須要什麼數據

在明確業務場景以後，那麼就該開始設計你的數據結構和須要的數據了

首先我我的其實在C端經歷了三年，從軟件實施到前端開發，C端是我比較熟悉的

一、設計舉例

我須要什麼數據，從常規的C端需求出發。設想我是一個產品，我如今須要一個數據分析收集系統，獲得數據進行後期的分析使用

從常規出發，頁面點擊量，停留時間，訪問人次，用戶的操做流程，誰訪問了，用戶地區等等。我發一張截圖

對你的數據進行分級

二、數據結構體

這裏我仍是偷懶用一下政採雲上面的ppt圖片

感受他們的格式很是好

2、你該怎麼上報你的數據（埋點）

一、請求用img的src進行請求數據上報

爲什麼用 1x1 像素的 gif 圖

一、沒有跨域問題

二、發 GET 請求以後不須要獲取和處理數據、服務器也不須要發送數據

三、不會攜帶當前域名 cookie！

四、不會阻塞頁面加載，影響用戶的體驗，只需 new Image 對象

五、相比於 BMP/PNG 體積最⼩小，能夠節約 41% / 35% 的網絡資源大小

注意：埋點也許是有差別的，可是從錯誤監控等等方面，這樣是沒什麼問題的

二、事件攔截和代理

事件攔截：委託到dom上面，利用img進行上報數據，navigator.sendBeacon方法

mousedown，touch，scroll，keydown

頁面進入離開：onload，berorOnLoad

這塊是埋點部分，一般能收集到用戶的操做行爲，頁面停留時間，離開等等

navigator.sendBeacon會有兼容問題，因此是作兼容性處理，具體我忘了。你們百度吧

3、錯誤監控（SDK）宋小菜

寫到這裏我感受有點能力不足了，實在是埋點和錯誤監控方面不僅是純粹的技術，和業務是很是緊密相關的。下面我會對ppt裏面的各路大神提供的錯誤監控代碼進行copy總結

一、RNSDK（reactNative）（宋小菜：Jimmy）

JS 端

• 錯誤捕獲

• ErrorUtils.setGlobalHandler 相似於 window.onerror

• Promise.rejectionTracking 相似於 Unhandledrejection

• ⽹網絡請求：替換 XMLHttpRequest，代理理其 send/open/onload 等方法

• ⻚頁⾯面跳轉：react-navigation 的 onStateChange 或者在 redux 集成方式中使用 screenTracking

• Native 端

• iOS 使⽤用 KSCrash 進⾏行行⽇日誌採集，能夠本地進⾏行行符號化
• 存儲捕獲到的數據（包括 JS 端和 native 端）統⼀一上報

const tracking = require("promise/setimmediate/rejection-tracking");
tracking.disable();
tracking.enable({
allRejections: true,
onHandled: () => {
// We do nothing
},
onUnhandled: (id: any, error: any) => {
const stack = computeStackTrace(error);
stack.mechanism = 'unhandledrejection';
stack.data = {
id
}
// tslint:disable-next-line: strict-type-predicates
if (!stack.stack) {
stack.stack = [];
}
Col.trackError(stringifyMsg(stack))
}
});複製代碼

二、小程序（宋小菜）

• 網絡請求: 代理全局對象 wx 的 wx.request ⽅方法

• ⻚面跳轉: 覆寫 Page 對象，代理其生命週期方法

import "miniprogram-api-typings"
export const wrapRequest = () => {
const originRequest = wx.request;
wx.request = function(...args: any[]): WechatMiniprogram.RequestTask {
// get request data
return originRequest.apply(this, ...args);
//
}
}複製代碼

三、小程序SDK實現（宋小菜）

/* global Page Component */
function captureOnLoad(args) {
console.log('do what you want to do', args)
}
function captureOnShow(args) {
console.log('do what you want to do', args)
}
function colProxy(target, method, customMethod) {
const originMethod = target[method]
if(target[method]){
target[method] = function() {
customMethod(…arguments)
originMethod.apply(this, arguments)
}
}
}複製代碼

// Page
const originalPage = Page
Page = function (opt) {
colProxy(opt.methods, 'onLoad', captureOnLoad)
colProxy(opt.methods, 'onShow', captureOnShow)
originalPage.apply(this, arguments)
}
// Component
const originalComponent = Component
Component = function (opt) {
colProxy(opt.methods, 'onLoad', captureOnLoad)
colProxy(opt.methods, 'onShow', captureOnShow)
originalComponent.apply(this, arguments)
}複製代碼

4、錯誤監控：貝貝集團：Allan：《React+Redux前端開發實戰》做者

貝貝集團很是的乾貨，這裏貼一下，所面臨的的環境是具備很是多的端，80+工程項目。

下面都是我ppt裏面原本來本摘抄下來，而且加上我的部分我的理解。主要是貝貝集團的分享太乾貨了。

直接從錯誤捕獲說吧

一、錯誤捕獲機制

• window.onerror：運行時錯誤捕獲

• window.addEventListener(‘unhandledrejection’)：promise 沒有 catch 錯誤

• try/catch 處理跨域腳本錯誤

• 其餘技術棧中（Vue、React）的錯誤捕獲

• window.addEventListener(‘error’)：資源加載錯誤

• … …

二、監聽window.onerror

當發⽣生 JavaScript 運行時錯誤（包括處理程序中引起的語法錯誤和異常）時，使⽤接口 ErrorEvent 的 error 事件將在 window 被觸發，並被 window.onerror() 調用

三、監聽 unhandledrejection 事件

當 Promise 被 reject 而且沒有獲得處理的時候，會觸發 unhandledrejection 事件。因此能夠對此事件進行監聽，將錯誤信息捕獲上報。

四、跨域腳本錯誤：Script error.

【方案1】：後端配置 Access-Control-Allow-origin、前端在 script 標籤配置 crossorigin 【方案2】：劫持原⽣方法，使⽤用 try/catch 繞過，將錯誤拋出

使用的是方案2：好處是不會直接報錯，能夠經過try/catch方式捕獲錯誤，而且不會影響js的運行。我我的在代碼編輯處理的時候也很是推薦。這個方式仍是寫eggjs的時候學過來的。配合primose方式能大大簡化代碼

五、其它技術棧——Vue.js

劫持 Vue.config.errorHandler （errorCaptured），當 Vue 的項目中發生錯誤時，將錯誤捕獲上報

六、其它技術棧——React.js

監聽 componentDidCatch，當 React 的項目中發生錯誤時，將錯誤捕獲上報

七、用戶行爲收集

這裏其實很簡單，不少時候錯誤的產品是須要復現方式的。就像咱們開發的時候測試會給你復現方式。若是你不知道什麼緣由產品的bug，那麼你也沒法正對性的去修復問題。也許修復了bug，反而致使系統崩潰了呢？

用戶行爲方面咱們能夠分爲：用戶行爲，瀏覽器行爲，控制檯打印行爲

針對的咱們能夠下面這樣作

【1】點擊行爲（用戶行爲）

使用 addEventListener 全局監聽點擊事件，將用戶行爲（click、input）和 dom 元素名字收集。當錯誤發生將錯誤和行爲一塊兒上報。

【2】發送請求行爲（瀏覽器器行爲）

監聽 XMLHttpRequest 對象的 onreadystatechange 回調函數，在回調函數執行時收集數據。

【3】頁面跳轉（瀏覽器器行爲）

監聽 window.onpopstate，頁面跳轉的時會觸發此方法，將信息收集

【4】控制檯打印（控制檯行爲）

改寫 console 對象的 info、warn、error 方法，在 console 執行時將信息收集。

5、錯誤或者埋點數據的處理

這裏比較關鍵，就不怎麼貼ppt了。並且仍是有一點我的理解的

一、埋點

埋點屬於業務分析行爲，更多的是基於業務自己方向進行數據分析。

埋點的關鍵是保證你的數據是一個連貫額閉環，可以充分的分析出用戶從進入到離開頁面所產生的一系列用戶行爲。

政採雲團隊在作的時候基本上作到了每一個按鈕都會進行埋點。

最後會生成一個熱力分析圖。（至關牛逼）來標識頁面中高頻操做的地方

二、錯誤監控存儲

這塊是重點講解部分

首先我在參與視頻學習的過程當中瞭解到幾個點

一、ES（elasticsearch）

下面說明來自簡書：elasticsearch簡寫es，es是一個高擴展、開源的全文檢索和分析引擎，它能夠準實時地快速存儲、搜索、分析海量的數據。

簡單來講就像是一個百度搜索引擎，快速準確

主要理解點：

爲何要用ES，由於他是全文索引的，效率很是快，可是mysql差了不少。

ES用來作數據一次處理，不做爲長期存儲，通常只會存留一個月的數據

二、數據庫存儲（MySQl）

當前期數據處理完成以後再進行存入數據庫，後續進行分析處理

三、存儲流程

錯誤上報——數據清洗——數據持久化——數據可視化——監控告警

四、關於數據清洗

關鍵在於分析數據，提取聚合重複錯誤，整理爲更小的數據，而後存儲

同時也是爲了減少服務器壓力，提供中轉站。

好比：貝貝和阿里釘釘都提到了須要對數據進行削峯處理，這個你們字面意思應該就能理解

貝貝集團的處理方式是：

一、每分鐘處理一次

二、每分鐘獲取數據10000條：超過就採樣入庫

三、同類型錯誤大於200條只記錄數量

四、處理無用的信息等等（上傳的數據由於是須要進行string處理，會出現亂碼或者無心義的字符）

核心就是：剔除重複，留下惟一

五、告警

告警的目的是可以快速通知負責人，對系統進行修復處理。同時告警，你們須要根據錯誤的狀況進行分析，歸類。如：通常錯誤，功能錯誤，頁面錯誤，系統錯誤等等的一個升級過程

好比：通常錯誤，功能錯誤能夠發送工做羣，郵件

可是系統級別錯誤那麼就是發短信了

6、其餘端的一個錯誤捕獲處理

這裏主要是摘抄自貝貝集團的ppt，基本上是截圖

一、node錯誤監控

一、初始化

node啓動的時候，須要獲取當前node一個初始id等信息。若是是集羣化處理那麼好比貝貝集團的狀況ZooKeeper裏面去獲取對應的業務 id 實現天網的初始化

二、錯誤捕獲機制

Node 端使⽤用 process 對象監聽 uncaughtException、unhandledRejection 事件，捕獲未處理理的 JS 異常和 Promise 異常

三、錯誤信息收集

捕獲到錯誤對象後，使⽤了第三方庫 stack- trace 進行解析，該庫會將錯誤堆棧解析成數組並獲取堆棧調用鏈路路中應用內文件的源碼。

主要是用第三方庫實現錯誤信息的一個可視化展現

二、weex錯誤監控

一、多端兼容

1）Weex 工程打包有兩套 Webpack 配置，但業務中統一引用的是 @weex/skynet

2）針對 Web 端打包的時候使用 replace-loader 這個 loader 將包替換爲 @fe-base/skynet

二、錯誤捕獲

1）前端爲客戶端提供業務的模塊名

2）經過 hybrid 接口將模塊名傳給客戶端

3）客戶端在捕獲到 weex 的錯誤發生時上報

三、小程序監控

小程序監控我不截圖了。寫太多了。我直接總結

首先小程序的app啓動的時候有一個錯誤捕獲函數：onError，經過這個能捕獲全局存在的錯誤

而後由於是C端，你須要獲取當前啓動的小程序的一個惟一id，除了appid以外就是和用戶信息有關的id，做爲記錄，而後上報爲本次的一個錯誤記錄起始。

四、客戶端監控

一、Android錯誤上報機制

使用系統提供的機制，實現 Thread.UncaughtExceptionHandler 接口，經過 uncaughtException 方法獲取崩潰錯誤信息，在應用初始化時替換掉默認的崩潰回調

爲⽅方便便前端開發理理解：

• uncaughtException：可類比爲前端的 window.onerror

• Thread.UncaughtExceptionHandler: 回調函數

二、ios錯誤監控

使用系統提供的錯誤捕獲機制，註冊了了 Objective-C 異常和 POSIX signal 的處理理鉤子，在發生崩潰的時候能夠經過鉤子函數記錄崩潰的信息。在下次 App 啓動時將錯誤上報。

五、吐槽

貝貝集團的我就差直接把ppt發出來了。感受太多能夠學習的了。知識面設計很是廣。你們能理解，就多理解下吧

七、總結自述

其實我以爲最重要的是錯誤的分析，和總結部分。

由於那都是別人踩過的坑。可是我我的自己沒有作過這塊。只能以技術角度去怎麼實現監控這塊入手。

當之後我本身作了那麼我想我會回過來翻翻。

這裏致歉下：本次文章基本是抄襲爲主，我的理解有限。

一方面是我的知識面不夠，還有一方面也是各位老師對於而已高了點。就像好高騖遠，可是基礎不牢，望而卻步

弄個小目標：寫一個自動監控函數，實現前端這塊的基本數據監控方式，就像那些非侵入式的代碼方式

致謝

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

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

看完如有啓發，點個贊吧