把前端監控作到極致

本文系第 12 屆 D2 前端大會議題《把前端監控作到極致》的總結文章，你也能夠直接查看 現場視頻 或 PPT。

原發於知乎專欄：zhuanlan.zhihu.com/ne-fe

說到監控，你們第一時間想到的確定是 Zabbix、Nagios 等各類強大的後端監控服務。誠然，這些強大的平臺經過採集服務器以及鏈路上各類中間件的數據，爲咱們的應用穩定起到了不可或缺的保駕護航做用。

然而在互聯網的另外一端，運行在用戶終端上的代碼卻缺乏這樣強大的監控能力。

對於資深工程師來講，想到或者作出一個前端監控方案並非什麼難事 —— 經過監聽全局的 window.onerror 事件捕獲到運行時錯誤，而後上報到採集端，再作一個頁面展現數據 —— 看起來確實只須要寫一個簡單的 CRUD 應用就能搞定。

本文將從 採集、數據處理、分析、報警 4 個維度進一步闡述如何把前端監控作到極致。

小福利

若是你尚未使用前端監控服務，那麼能夠先看看這個小福利。只用兩行代碼就能打造一個前端異常實時監控平臺，還帶報錯數統計功能。

其實現思路正如開題所言，經過 window.onerror 採集到全部的未捕獲異常，並經過 new Image 的方式構造一個 404 的 HTTP 請求，最後在服務端實時過濾 access.log 中匹配的請求並計數便可。

實際運行效果以下：

瀏覽器端效果

服務端效果

固然，這個監控系統並不能直接應用在生產環境。要讓監控真正發揮價值，還須要從採集、處理、分析、報警等多個方面進行優化加強。

採集

Script Error

當咱們採集前端報錯的時候，第一個遇到的問題就是 Script Error。Script Error 不是一種具體的錯誤，而是瀏覽器對跨域錯誤出於安全機制考慮的一種處理方式。

一個前端錯誤爲何涉及到了「安全」問題呢？2006 年一位安全研究人員發現第三方腳本能夠經過頁面中報錯信息的不一樣判斷當前用戶是否登陸了指定的網站，並向 Webkit 項目提出了 相關的 issue。7 年以後，各大瀏覽器廠商基本都支持了這一安全設定。

Webkit 源碼中對 Script Error 的處理

簡單的說，若是你的頁面和頁面中引用的 JavaScript 文件不一樣源（協議、域名、端口不一致），那麼這些腳本拋出的錯誤都屬於跨域錯誤。那麼咱們在作前端監控捕獲這些錯誤的時候，應該怎麼避免採集到 Script Error 呢？

答案是 crossorigin 屬性。這是一個應用在 <script> 標籤上的屬性，添加以後便可保證即便是跨域錯誤也能捕獲到完整的錯誤信息。然而事情真的只有這麼簡單嗎？

crossorigin 生效須要服務器端和瀏覽器端同時支持。服務器端支持比較簡單，即返回跨域腳本的服務器（通常爲 CDN 服務器）正確的帶上 CORS 響應頭 —— Access-Control-Allow-Origin: * —— 便可，目前常見的 CDN 服務均支持這一特性。而瀏覽器端的支持狀況就沒有這麼樂觀了。

crossorigin 屬性前端支持狀況

能夠看到，crossorigin 前端支持問題的重災區發生在 IE 和 Safari 上。IE 這個拖油瓶出現問題是情理之中，Safari 在 9.0 以前的版本也不支持 crossorigin 就說不過去了。這也直接致使了許多運行在 iOS Webview 中的業務沒法正確捕獲到錯誤。

突破跨域報錯限制

那麼怎樣能突破 crossorigin 的這些限制，儘量的捕獲到更詳細的錯誤呢？

首先最簡單也是最直白的方式，就是把頁面中全部的跨域資源放在跟頁面一樣的域下，這樣腳本拋出的錯誤再也不是跨域錯誤，也就不存在 crossorigin 的使用場景了。固然同域化以後也會遇到不少問題，好比沒法利用 CDN 的性能、頁面單域資源併發加載限制等等。

另外一種解決方案是經過 Patch 原生方法來儘量的捕獲到錯誤，這也是不少監控腳本默認提供的能力。好比說咱們能夠經過以下代碼來 Patch 原生的 setTimeout 方法：

const prevSetTimeout = window.setTimeout;

window.setTimeout = function(callback, timeout) {
  const self = this;
  return prevSetTimeout(function() {
    try {
      callback.call(this);
    } catch (e) {
      // 捕獲到詳細的錯誤，在這裏處理日誌上報等了邏輯
      // ...
      throw e;
    }
  }, timeout);
} 複製代碼

同理，咱們還能夠 Patch 更多的原生方法，好比 Array.prototype.forEach、setInterval、requestAnimationFrame等等。

誠然這種方法能幫咱們儘量捕獲到更多異常，可是由於 Patch 了 JavaScript 原生的方法，老是感受會存在不少的不肯定性。

在這裏還要提一下去年 QCon 上百姓網前端同窗劉小杰提出的一種基於 Babel 的自動添加 try...catch... 的方法，感興趣的同窗能夠去深刻看看，會有很多啓發。

框架層解決方案

在很多現代前端框架中，都提供了框架層的異常處理方案，好比 AngularJS 的 ErrorHandler 和 Vue 的 Vue.config.errorHandler。在這裏咱們以 React 16 的 componentDidCatch 爲例，說明如何使用框架的能力採集錯誤。

如下是 React 官網中的示例：

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  componentDidCatch(error, info) {
    this.setState({ hasError: true });

    // 在這裏能夠作異常的上報
    logErrorToMyService(error, info);
  }

  render() {
    if (this.state.hasError) {
      return <h1>Something went wrong.</h1>;
    }
    return this.props.children;
  }
}

複製代碼

在使用時，用 ErrorBoundary 包裹你的業務組件便可：

<ErrorBoundary>
  <MyWidget />
</ErrorBoundary>

複製代碼

數據處理

傳統的監控服務通常都會使用 MySQL 等數據庫進行數據持久化，但當數據量指數級增加時，MySQL 這種 OLTP 數據庫已經再也不適合用來提供監控數據分析服務。

在大數據時代，搭建一套標準化的、針對監控業務的大數據解決方案已經不是什麼難事，下圖即爲一個簡單的數據架構示意圖：

在數據處理過程當中，值得一提的是數據採樣率的功能設計。

不難看出目前的採樣率設計方案都或多或少存在缺陷和妥協，那麼有沒有一種更優的解決方案呢？

通過大量的實踐後，咱們認爲在日誌服務進入數據處理流程以前進行採樣率控制是比較理想的方案，理由以下：

1. 日誌寫入成本低
2. rotate 機制保證存儲不會浪費
3. 瞭解真實打點請求數據量
4. 避免採集端繞過採樣率限制

分析

當故障發生時

解決了數據採集和處理的問題，咱們應該怎麼着手進行分析呢？讓咱們先看一個真實案例：

當你吃着火鍋唱着歌的時候，忽然看到實時監控數據暴漲，這個時候你的第一反應是什麼呢？是否是手足無措不知道應該怎麼處理？當線上出現緊急情況時，咱們的首要思路是找到問題觸發的特徵，好比是否集在某個頁面或者某種瀏覽器等等。

經過監控平臺提供的分析功能，初步定爲到問題緣由後，再進行深刻的調查。

報錯數高必定是不穩定嗎

這裏試舉兩個反例來講明報錯數高不必定就是前端不穩定。

如上圖所示，雖然該應用 1 天爆出了上萬的 JavaScript 異常，可是咱們在分析過程當中發現，95% 的報錯都集中在 3 個 userId 上。再對這 3 個 userId 進行深刻的調查不難發現，這是 3 個爬取數據的爬蟲帳號，不巧爬數據的腳本寫的有 Bug，被前端監控系統忠實的捕捉到了。

又如上圖所示，某天的數據出現暴增，多是由於頁面的訪問量出現暴增。

所以咱們不難發現，僅僅經過報錯數的多少不足以判斷系統是否穩定。

異常波動必定有元兇

前端發生故障最多見的緣由就是新發布的版本存在 Bug，那麼這種問題在監控平臺中如何提供分析思路呢？

固然，也並非全部的波動都是前端變動引發。好比說後端接口忽然故障，也會致使前端由於沒法讀取到某個接口結果而報錯。

報警

說到報警，絕大多數的監控平臺都提供規則報警的能力。然而規則報警最大的問題在於隨着業務的不斷髮展，本來配置的規則將會出現閾值太低或太高的問題。若閾值配置太低，則會產生大量的誤報警，繼而引發整個監控能力的報警疲勞。

爲了解決規則報警的問題，監控平臺能夠引入一些簡單的數學模型來解決時序數據的異常識別工做。以最多見的高斯分佈（正態分佈）爲例，利用 3-sigma 原則能夠快速判斷某一時刻的報錯數是否知足機率分佈，繼而能夠產生報警：

固然，這樣的報警模型還存在很是大的優化空間，好比對數據週期性、季節性的處理，又好比過濾掉某些可能影響平均數的極高值等。

結語

前端監控看似簡單，但想要監控真正發揮價值，還須要從各個方面進行不斷的優化和打磨。固然，最重要的是，要意識到前端監控的必要性，及早開始進行監控，才能更好的避免線上故障的產生。

若是你對咱們正在作的事情有興趣，歡迎加入阿里巴巴和咱們一塊兒親手打造屬於本身的數據產品，簡歷請發 shuangyang.ys@alibaba-inc.com