前言：

如果你碰巧是一名前端開發，而又碰巧在維護著一個對可用性有極高要求的站點，那么也許你我有過共同的苦惱：如何在第一時間發現線上出現的前端異常？畢竟前端不是每天都可以過網頁裸奔節，線上的JavaScript錯誤也足以讓用戶抓狂地拿起他們的投訴電話。。。每天心驚膽戰發布的日子不好過吧？

是時候改變下了，讓心驚膽戰見鬼去吧！我的目標很簡單：要在用戶和boss發現異常之前就徹底修復問題，其余的時間充分地享受高質量生活:）

一：前端異常監控系統的構建目標

在對被監控頁面無侵入的前提下，提供7*24小時全天候的監控任務，第一時間發現“裸奔”、“半裸奔”頁面或是有JavaScript異常拋出的頁面，并給網站前端負責人提供短信、郵件等方式的報警服務。

可以說，前端異常監控系統主要是解決兩大異常情況：a. 頁面上有javascript異常  b. 各種因素造成的頁面的樣式丟失。我先分別介紹下兩種這兩種異常的解決思路：

二：JavaScript的異常監控

由于客戶端瀏覽器環境的不同，在開發環境中能夠工作的代碼，并非就能夠在用戶的電腦上正常運行，各種畸形瀏覽器造成的問題弄得我們很頭大，如果能像后端開發那樣可以隨時地查看服務器端錯誤日志就好了！可為什么不呢？

JavaScript語言自身就提供了try catch的異常處理語法，我們假以利用的話，就能夠在增強前端應用魯棒性的同時，又可以把捕獲到的異常拋送給前端異常監控系統，以錯誤日志的形式記錄到數據庫中。

給應用添加異常處理功能，我們是可以充分發揮javascript語言是動態語言這一優勢的。我可不想為了添加異常處理而在代碼中寫N多的try-catch語句。 我的思路是：通過JavaScript類模塊在應用中注冊的時候，遍歷類模塊中的每個函數，然后統一的加上try-catch處理，這樣前端里面的所有函數就都在異常處理的范圍之內了。怎么樣，是不是要比Java等靜態語言cool很多？ 代碼示例如下：

有了以上的全局異常處理函數之后，解決線上的JavaScript異常就是小菜一碟，只需要定義好錯誤message的格式，并在catch語句中向異常監控系統的固定接口發送請求即可。我們可以在錯誤消息中發送關于錯誤的瀏覽器信息，JS模塊信息，函數信息，或具體的錯誤消息等，要傳送哪些信息全看你自己的需要。在FdSafe異常監控系統中，我們傳輸了如下錯誤信息：

三：樣式丟失的異常監控

如果你的頁面在不該裸奔的時候突然裸奔了，那就是嚴重的可用性問題，需要前端同學在第一時間定位問題并迅速修復。引發“裸奔”的可能性很多，也許是CSS文件404了，也許是CSS文件@import url的問題，但是最終的表象只有一個，那就是頁面樣式突然發生極大改變。

在fdsafe系統中，我們使用了圖片對比的方法來探測線上頁面發生“裸奔”的現象，原理上很簡單：對于被監控頁面的URL，我們讓監控系統保留其前一天頁面被瀏覽器渲染后的截圖，然后讓監控系統周期性的定時抓取線上頁面的截圖，兩張圖片做相似度對比，如果相似度差值超過一定的閾值，則會觸發報警條件。

頁面的截圖我們是使用QT的webkit內核渲染并截取的，當然也推薦使用selenium的瀏覽器截圖功能。而圖片相似度的算法很多，我們最終采用的是OpenCV中的cvCompareHist算法。

四：其它的異常監控

除了樣式丟失及javascript異常之外，前端還是有很多其它異常可以通過系統來監控的，比如說JS、CSS文件的404錯誤，HTML源碼的閉合異常，或JS、CSS文件的壓縮異常等。fdSafe系統能夠通過添加插件的方式來提供對不同異常的監控，然后統一匯總到異常日志中。

五：系統總體框架圖

搭建前端的異常監控系統，自然也要體現我們前端的特色，后臺的系統我們是基于NodeJS來實現的，它主要完成兩個功能：

1）定時抓取被監控頁面的HTML源碼，并分析是否存在頁面樣式丟失異常或是其它異常。

2）接受來自用戶瀏覽器發送的JavaScript異常。

一旦異常發生，且超出設定的允許閾值，則觸發報警條件，給負責人發送報警短信，系統原理圖如下：

六：總結

隨著Web應用朝著富客戶端方向的發展，前端應用的可用性重要性越來越高，搭建前端異常監控系統的必要性也是越來也高，希望本文能夠給大家提供一些思路上的啟發。

原文鏈接