一步一步搭建前端監控系統：如何監控資源加載錯誤？

摘要： 資源加載失敗會破壞產品功能以及用戶體驗....

• 做者：一步一個腳印一個坑
• 原文：搭建前端監控系統（三）靜態資源加載監控篇

Fundebug經受權轉載，版權歸原做者全部。

一步一步搭建前端監控系統系列博客：

• 一步一步搭建前端監控系統：JS錯誤監控篇
• 一步一步搭建前端監控系統：如何將網頁截圖上報？
• 一步一步搭建前端監控系統：接口請求異常監控篇
• 一步一步搭建前端監控系統：如何定位前端線上問題？
• 一步一步搭建前端監控系統：如何記錄用戶行爲？
• 一步一步搭建前端監控系統：如何監控資源加載錯誤？

怎樣定位前端線上問題，一直以來，都是很頭疼的問題，由於它發生於用戶的一系列操做以後。錯誤的緣由可能源於機型，網絡環境，接口請求，複雜的操做行爲等等，在咱們想要去解決的時候很難復現出來，天然也就沒法解決。 固然，這些問題並不是不能克服，讓咱們來一塊兒看看如何去監控並定位線上的問題吧。

背景

市面上的前端監控系統有不少，功能齊全，種類繁多，無論你用或是不用，它都在那裏，密密麻麻。每每我須要的功能都在別人家的監控系統裏，手動無奈，罷了，怎麼才能擁有一個私人定製的前端監控系統呢？作一個自帶前端監控系統的前端工程獅是一種怎樣的體驗呢？

這是搭建前端監控系統的第三章，主要是介紹如何統計靜態資源報錯，跟着我一步步作，你也能搭建出一個屬於本身的前端監控系統。

若是感受有幫助，或者有興趣，請關注 or Star Me 。

請移步線上： 前端監控系統

上一章介紹瞭如何作JS錯誤監控，還有一種錯誤是靜態資源加載報錯，不少時候資源加載報錯對前端項目來講是致命的，由於靜態資源加載出錯了，有可能就會致使前端頁面沒法渲染，用戶就只能對着一個空白屏幕發呆，不知所措。由於忽然有一天，咱們的線上環境爆出了大量的白屏錯誤，通過很長時間的排查，終於定位到問題緣由：咱們使用的CDN路徑不知道怎麼的，把咱們的https協議所有指向了http協議，在安全協議下沒法訪問非安全協議的資源，致使了大量的白屏。因此我決定增長靜態資源監控功能，以應對將來的未知狀況。

那麼，下邊咱們就進入正題：

如何監控前端靜態資源加載狀況？

正常狀況下，html頁面中主要包含的靜態資源有：js文件、css文件、圖片文件，這些文件加載失敗將直接對頁面形成影響甚至癱瘓，全部咱們須要把他們統計出來。我不太肯定是否須要把全部靜態資源文件的加載信息都統計下來，既然加載成功了，頁面正常了，應該就沒有統計的必要了，因此咱們只統計加載出錯的狀況。

先說一下監控方法：

1）使用script標籤的回調方法，在網絡上搜索過，看到有人說能夠用onerror方法監控報錯的狀況， 可是通過試驗後，發現並無監控到報錯狀況，至少在靜態資源跨域加載的時候是沒法獲取的。

2）利用 performance.getEntries()方法，獲取到全部加載成功的資源列表，在onload事件中遍歷出全部頁面資源集合，利用排除法，到全部集合中過濾掉成功的資源列表，即爲加載失敗的資源。 此方法看似合理，也確實可以排查出加載失敗的靜態資源，可是檢查的時機很難掌握，另外，若是遇到異步加載的js也就歇菜了。

**3）**添加一個Listener（error）來捕獲前端的異常，也是我正在使用的方法，比較靠譜。可是這個方法會監控到不少的error, 因此咱們要從中篩選出靜態資源加載報錯的error, 代碼以下：

/**
   * 監控頁面靜態資源加載報錯
   */
  function recordResourceError() {
    // 當瀏覽器不支持 window.performance.getEntries 的時候，用下邊這種方式
    window.addEventListener('error',function(e){
      var typeName = e.target.localName;
      var sourceUrl = "";
      if (typeName === "link") {
        sourceUrl = e.target.href;
      } else if (typeName === "script") {
        sourceUrl = e.target.src;
      }
      var resourceLoadInfo = new ResourceLoadInfo(RESOURCE_LOAD, sourceUrl, typeName, "0");
      resourceLoadInfo.handleLogInfo(RESOURCE_LOAD, resourceLoadInfo);
    }, true);
  }

咱們根據報錯是的e.target的屬性來判斷它是link標籤，仍是script標籤。因爲目前我關注對前端形成崩潰的錯誤，因此目前只監控了css，js文件加載錯誤的狀況。

首先，咱們要作實時監控和預警，依然關聯了7天之前同一時間端的數據，若是某個時間段出現錯誤量暴增，能夠發出警告，及時制止。　　

而後，咱們還須要知道更多詳細的信息，以下圖。 不看不知道，一看嚇一跳。雖然線上環境並無給咱們報出這麼多的問題，可是能夠看到，天天仍是有不少的靜態資源加載報錯，有些是很重要的靜態資源文件，是必然會致使頁面渲染失敗的，因此必需要解決。

解決方案

• 統計出天天的量，列出天天加載報錯的變化，點擊圖表的bar, 能夠看到天天的數據變化，以做對比。
• 分析出靜態資源加載出錯主要發生在哪些頁面上，縮小排查的範圍。
• 分析出影響用戶的人數，也許不少錯誤就發生在一我的身上，減小盲目排查。

靜態資源加載監控就完成了， 這裏還有一些細節須要處理， 來幫助排查問題， 可是我一時半會兒也想不出來，暫時就說到這裏吧。

關於Fundebug

Fundebug專一於JavaScript、微信小程序、微信小遊戲、支付寶小程序、React Native、Node.js和Java線上應用實時BUG監控。 自從2016年雙十一正式上線，Fundebug累計處理了20億+錯誤事件，付費客戶有陽光保險、核桃編程、荔枝FM、掌門1對一、微脈、青團社等衆多品牌企業。歡迎你們免費試用！