背景

痛點及問題梳理

總結分析與設計

有了問題，就要考慮解決方案了。調研了業內比較出名的監控方案，有Sentry、ARMS、Fundebug等。一是瞭解一下大致的實現思路，二是評估一下直接接入的可能性。如果要直接接入，那肯定挑一個免費開源的，Sentry當屬首選。但深入調研後，發現要接入並部署Sentry，後端側要做的事情工作量其實更大。當下面臨的情況是業務上等着用，資源投入又不可能太多，於是打算先找一箇中間過渡方案，依託現有錯誤採集服務端的資源，在前端側快速調整一下，來支持線上業務。同時也要爲後續接入Sentry、或是中臺的監控方案預留可擴展性。
基於這種考慮，這次調整的重點放在數據採集上，主要解決採集錯誤信息不夠充分的問題，來緩解問題定位上的痛點。至於數據採集上來後的可視化平臺，數據分析報表等比較重的工作，還是考慮後續通過接入第三方監控系統或中臺的服務來解決。
接下來看一下具體的調整措施：
1、對原有監控探針做一些調整，通過在window上添加監聽和對事件劫持來補全之前漏抓的場景；
2、強化靜態代碼掃描，lint規則中加入針對script標籤crossdomain的檢查。對於被允許CORS域名下的script標籤，如果沒有crossdomain屬性直接lint報錯。暫不對document.createElement("script")做劫持來添加crossdomain屬性，因爲第三方js中可能會用到，且有些域名不允許跨域，可能產生加載報錯，所以只在lint環節打印出來，人工確認一下；
3、針對偶發類錯誤設計一套場景還原方案，通過採集更多維度的信息來輔助還原異常現場，後面會具體講到具體方案；
4、增加採集器自檢能力。在URL中預留一個自檢查開關，默認處於關閉狀態，需要自檢時可手動打開。例如/user/brokerhomeV2?xxx_trace=true。開關打開後會異步執行document.createElement("script")來加載固定地址下的一段腳本，該腳本里是故意設計好的一些報錯用例，方便在線驗證。這個腳本獨立發佈，可以任意修改。同時，開關打開後，日誌上報方法會在控制檯打印上報內容，便於開發人員及時確認。
5、在1的基礎上對監聽和事件劫持做wrap，預留對接入第三方監控的兼容性。
改造前後方案對比：

至於vue或react裏的異常，用window.onerror是捕獲不到的。需要藉助vue的errorHandler，react的ErrorBoundary來處理。以vue爲例，實現思路大致如下：

function wrapErrorHandler(ErrorDetector, Vue) {  
  Vue = Vue || window.Vue;  
  
  if (!Vue || !Vue.config) return;  
  
  var _oldOnError = Vue.config.errorHandler;  
  Vue.config.errorHandler = function VueErrorHandler(error, vm, info) {  
    var metaData = {};  
  
    // vm and lifecycleHook are not always available  
    if (Object.prototype.toString.call(vm) === '[object Object]') {  
      metaData.componentName = formatComponentName(vm);  
      metaData.propsData = vm.$options.propsData;  
    }  
  
    if (typeof info !== 'undefined') {  
      metaData.lifecycleHook = info;  
    }  
    
    ErrorDetector.captureError(error, {  
      extra: metaData  
    });  
    
    if (typeof _oldOnError === 'function') {  
      _oldOnError.call(this, error, vm, info);  
    }  
  };  
} 

總結

對於頁面錯誤信息，我們把它大致歸爲兩類。一類是頁面加載過程中就會報出來的錯誤，一類是頁面加載完成後，需要用戶在特定操作下，纔會報出的錯誤。第一類錯誤理論上在瀏覽器（UA）確定的情況下，用戶會話ID和URL確定的情況下，該類錯誤絕大多數可以說是必現的。這類錯誤通過現有的UA、用戶會話ID和URL可以直接還原場景。不需要再採集用戶行爲信息和截屏。第二類就是由用戶交互產生的，這類正是場景比較複雜，文章開頭例子中難以復現的那種，需要藉助採集用戶行爲信息和截屏來還原現場。
這兩類信息在採集時需要區分對待，第一類信息只採集終端信息、訪問信息、錯誤信息，第二類信息才需要加上行爲信息和截屏信息作爲補充。對於這塊的處理是通過在window.onload配置一個開關來實現，開關實現如下：

$(window).load(function(){  
    ErrorDetector.pageLoadComplete = true;  
})  

window.setTimeout
window.setInterval
window.requestAnimationFrame
EventTarget.addEventListener
EventTarget.removeEventListener
XMLHTTPRequest.open
XMLHTTPRequest.send
window.fetch
History.pushState
History.replaceState
接下來看一下數據分片
頁面加載完成後，開始錄製用戶行爲，行爲數據以隊列形式存放在監控探針js的全局變量上。這個變量上的內容會在異常發生時，被上報給後臺服務。但這個錄製什麼時候停，什麼時候重新開始錄製，卻需要制定一個策略。我們的方案採取以URL變化和交互error發生兩個時刻來做切割。理由如下：
1、URL變化意味着場景切換，場景切換前上下文的交互細節不需要過多關注。URL、用戶會話ID、瀏覽器(UA)能夠共同確定交互類錯誤發生前的最近上下文環境；
2、同一頁上發生多次異常，沒有必要每個上報內容都包含頁面一進來到報錯時點的全量交互信息，以報錯點切割開就行。每段報錯切片會按時間順序上報給後臺，將它們合在一起可以形成上下文鏈，這個從時間上可以確定。
3、採集數據不是越多越好，對網絡傳輸，數據存儲都會是挑戰，甚至會淹沒有效數據。所以應避免上報過多冗餘數據。
基於以上理由，每次上報的用戶行爲採集切片方案設計如下：

至於SPA類的web，需要監控探針暴露一個方法給到router切換時來調用，以處理清空隊列等動作。
聊完了用戶行爲抓取，再來看屏幕截取。
理論上拿回用戶行爲日誌後，可以在本地瀏覽器環境中注入上下文後，逐一執行來進行回放，從而還原現場。但是，現實情況下要搭建這樣一套交互回放系統，其成本投入卻是現階段不能承受的，所以放棄，還是老老實實截圖去。雖說截圖對於問題定位不是必須的，但有總比沒有好，一圖勝萬言，查問題效率上是有很大提升的。實踐下來，截屏+stack trace絕對是問題定位大殺器。
接下來看看截屏數據採集的具體方式：
截屏是藉助html2canvas插件來實現的。通過將當前頁轉成canvas後再序列化爲base64，base64的內容會和行爲數據隊列序列化後的結果一起上報給服務端。
截屏轉base64代碼如下：

function captureScreen() {  
    var targetDom = document.querySelector("body");  
    html2canvas(targetDom, {  
        useCORS: true,  
        allowTaint: false  
        height: targetDom.scrollHeight,  
        width: targetDom.scrollWidth,  
    }).then(function(canvas) {  
        var context = canvas.getContext('2d');  
        context.mozImageSmoothingEnabled = false;  
        context.webkitImageSmoothingEnabled = false;  
        context.msImageSmoothingEnabled = false;  
        context.imageSmoothingEnabled = false;  
        var quality = 0.92;  
        var base64Image = canvas.toDataURL('image/png', quality).substring(22);  
        ErrorDetector.accidentScene.img = base64Image;  
    })  
} 

代碼中imageSmoothEnabled = false是爲了提高圖片清晰度，抗鋸齒用的。由於html2canvas中用到了Promise，對於低版本瀏覽器需要加入promise墊片，這裏用的是promise-polyfill。至於base64是否再要做壓縮，默認圖片質量下實際生成的大小在220~450K之間，在保證清晰度情況下，這個大小範圍是可接受的。

異常上報

於是上報方案設計如下：
1、交互場景error只蒐集js運行時這類錯誤，在window.onerror中採集。錯誤唯一性通過message，source，lineno，colno加分隔符後拼接成的字符串作爲唯一標識（unique key）。
2、window.onerror中區分對待頁面加載過程中的錯誤和頁面加載後由用戶行爲操作產生的錯誤。通過在window.onload中設置加載完畢標誌，加載中錯誤走原來通道上報，加載後走場景還原上報通道。這樣可以有效降低圖片上報數量。
3、同一錯誤只在客戶端上報一次。利用客戶端存儲將上報過錯誤的唯一標識存下來，下次上報前比對是否已上報過，已上報過則忽略，否則繼續上報。
4、同一錯誤服務端只採集一次。由於用戶基數大，僅靠客戶端去重是不能有效降低上報總量的。搭建一臺node配redis，用來存儲上報過錯誤的唯一標識。客戶端上報前會先拿唯一標識去服務器端作比對，如果沒有上傳過才上傳，上傳後唯一標識會存入本地客戶端存儲中，下次直接在本地比較時就會攔截，不會給node服務帶來壓力。
爲了在客戶端做一層去重，需要在本地保留上傳過錯誤的摘要。本地存儲採用indexedDB，以隊列存儲，先進先出，大小配30（數字是按線上交互類報錯的單個用戶平均數放大5倍後的預估值）。

實際去做的時候，發現最初的方案有些問題

1、首先，用message+source+lineno+colno來唯一標識特定錯誤是不精確的。一些錯誤是由基礎方法裏拋出來的，報錯位置相同，但產生原因不相同。要唯一標識出特定原因的錯誤還是得用stack trace。
2、存儲用indexeddb的話，有低版本瀏覽器兼容問題。爲了兼容低版本瀏覽器還得單獨實現一套基於localstorage的隊列存儲，做是可以做，但就當下而言不經濟。
針對上面的問題，採取如下調整：
對於第一個問題，把唯一標識換成stack trace。但limit放大後的stack trace太長了，還有格式問題，直接拿來做unique key不太合適。所以對其md5一下後作爲key使用。
至於第二個問題，放棄indexeddb直接用localstorage。但這樣一來，如果還是走每次上報就更新localstorage的模式的話，要做size超限判斷、刪除等操作就很麻煩。思來想去後，決定採用批量更新模式。
每次發生場景上報後不直接寫localstorage，而是放到js內存對象中更新，以map形式存儲。在window.beforeunload時，將map對象序列化後一次性存儲下來。在頁面載入時，監控探針也能一次性從localstorage裏取到map後反序列化到內存變量中，這對於後續的判重來說是比較方便的。至於更新策略，是通過保留引用在隊列中，通過維護隊列的先進先出從而更新map對象裏的內容的。

至此，方案調整完畢。

總結

參考文獻

作者簡介

孫淘熔：HBG二手房技術部資深開發工程師，18年3月加入公司，目前負責中國網絡經紀人、網絡門店、家裝店鋪等前端側工作，對面向B端的前端開發有深入瞭解。

閱讀推薦

相關文章