提到監控系統，大部分同學首先想到的是后端監控。很明顯，比如檢測服務器性能，數據庫性能，API 的訪問流量，以及各種服務的運行情況等等，都與后端息息相關。而前端更多承擔的是 UI 展現的角色，主要關注頁面怎么排版設計，好像沒什么需要監測的地方，因此一直以來都沒有涉及到監控的概念。

于是呢大家就一致認為：只要后端穩定可控，應用就是穩定可控的，可實際情況真的是這樣嗎?

近年來，前端發展日益迅猛，得益于 JavaScript 的持續進化和瀏覽器功能的不斷增強，前端能做到的事情越來越多，相應的前端應用的復雜度也越來越高。以前我們壓根不會遇到的問題，現在蹭蹭蹭的一股腦都冒出來了。

舉個例子，小明是個前端程序員，有一天用戶反饋某頁面某按鈕點了沒有反應。小明立刻找到那個按鈕，輕輕一點，咦?正常的呀。然后小明又用了幾個不同的賬號測試，依然是正常的。這下可把小明難倒了。

怎么辦?我相信全天下的前端程序員們遇到奇怪問題的反應是一樣的。小明這樣告訴用戶：可能是瀏覽器緩存問題，不行強制刷新一下，或者退出登錄試試? 用戶按照小明的建議操作一番，果然奏效!于是給小明發來了一連串的“感謝 ??”。小明尷尬一笑，連忙回復“小意思”。

過了兩天，又有一個用戶反饋了同樣的問題。小明又祭出了上面的萬能解決大法，依然奏效?？墒菃栴}真的解決了嗎?沒有啊!然而小明嘗試過很多遍都無法復現異常，可能原因有很多，比如：

1. 數據問題，可能取不到某個屬性。
2. 前端問題，JS 代碼執行異常。
3. 接口問題，可能接口無響應，或沒有返回預期的值。

然而正常情況下是沒有問題的，小明多次測試也都正常，一定是在某種特定場景下才會出現這個問題，但是我們無法判斷，捕捉不到。

像這類 Bug 潛伏在我們的系統中，仿佛地雷一樣，指不定什么時候就會爆。最尷尬的是即便它爆了我們也很難發現，這就導致我們的“排雷行動”困難重重。

某個陽光明媚的下午，小明坐在馬桶上思考人生。突然腦海中一道靈光閃過，小明想到：“如果在用戶觸發異常的那一刻，系統能自動獲取到異常的數據并保存起來，然后在后臺的某個地方能看到這些數據，我不就可以立刻找到錯誤原因了嗎?”

小明一拍大腿，對呀!我怎么沒有早點想到呢?這樣的話，只要發生異常我們就能自動捕獲到異常數據，如果再遇到線上報錯，我們不需要用戶反饋，自己就可以發現，而且能馬上定位錯誤原因，這不是一舉兩得?

我相信許多前端前輩們也曾經被上述的問題所困擾，然后也像小明一樣，慢慢的有了這個思路：“將報錯時的異常數據存下來供后續排查”。在這個思路不斷實踐的過程中，逐漸演變成了今天的前端監控。

當然了，今天的前端監控并不僅僅是監控異常數據，任何有利于產品分析的數據都可以加入監控。所以我認為前端監控，就是指采集用戶使用系統過程中產生的關鍵數據，存儲到數據庫，后續可以查找和分析，這樣的整套實現就被稱為前端監控系統。

前端監控具體能解決什么問題?

上面用一個例子推導出前端監控出現的背景，粗略的說了下它如何追蹤線上報錯問題，大家應該初步了解了前端監控的意義。現在我們把目光聚焦在項目上，再詳細探究一下它具體能解決哪些問題。

異常報錯問題

首先就是異常報錯的問題。就如例子中的場景一樣，線上發生異常，有時候我們難以復現，甚至如果沒有用戶反饋，我們都不知道有這個問題，這樣就給用戶傳遞了一種我們的產品很不穩定的感覺。因此前端監控是線上產品穩定和異常及時反饋的非常關鍵的保障。

當然了，除了前端的異常，我們同樣可以捕獲 接口異常。有的時候前端程序員們自嘲自己是“背鍋俠”，產品，測試，用戶，遇到問題首先找前端，不管是不是前端的問題，前端先頂，再花時間定位錯誤。有的時候領導脾氣不好，上來先劈頭蓋臉一頓罵，卑微前端也不敢說話，因為啥問題得排查后才清楚，結果排查完后是接口的問題，白挨了一頓罵，心里就非常不爽。

但是如果有了前端監控，我們就能馬上拿到異常發生時的錯誤信息，頁面，地址，參數等，什么問題一查便知。下一次遇到線上事故，前端就可以從容不迫客觀公正的說這是哪一方的問題。如果遇到甩鍋行為，前端也能勇敢說不，畢竟我證據在手，豈容你說吼就吼?

性能檢測問題

追蹤異常是前端監控最實用的地方，但不光如此，性能監控 也是非常關鍵的部分。

當下的前端工程體量很大，如果代碼質量不高，或者項目架構設計不合理，很容易遇到性能問題。性能問題比如首屏加載時間，頁面是否卡頓，白屏，資源重復請求等，可以通過數據采集，比如計算渲染時間，請求接口數量，請求資源總量等，對某個頁面進行監控，及時發現性能問題。

那么除了可以“解決問題”，前端監控還有哪些價值?

運營反饋工具

其實前端監控除了可以幫助程序員不斷優化和完善應用，對產品和運營同學有同樣不可或缺的作用。具體來說就是通過“埋點監控”來收集用戶的行為數據，則可以對線上產品的使用情況作出統計分析，比如整體的 PV/UV，某個功能的訪問量，訪問時段，點擊率等等數據。這些數據可以幫助產品和運營了解實際情況，進而改進產品功能。

這些行為數據的收集，可以非常精準的描繪出某個功能或者某個人的實際使用情況。當然采集的數據量也要比異常數據大的多。相比來說，異常監控是只有發生異常才會收集數據，而行為數據則是，只要用戶使用我們的產品，與產品發生交互，理論上這些數據都要收集起來。

當然監控是多方面的，收集哪些數據視情況而定。總之你想了解產品的任何情況，都可以通過設計采集規則然后收集數據來實現，這方面是非常靈活的，并不僅僅限于大家熟知的那幾個指標。

為什么要選擇自研?

前端監控發展到現在，必然會有成熟的第三方平臺。目前國內最常用的有三個：

• sentry
• webfunny
• fundebug

首先 sentry 和 fundebug 這兩個平臺是付費的，而且你的數據越多費用越高，相當于是數據托管平臺。webfunny 雖然可以私有化部署，但是它的功能是固定的，沒法改代碼，這就是它的缺點：不夠靈活，無法定制功能。

所以目前雖然市面上已經有成熟的監控系統，但依然有很多團隊選擇自研。一是數據可以保存在自己的服務器上，不用另外花錢;二是靈活性強，可以自定義功能，比如你可以在觸發異常時，接入自己的釘釘或企業微信消息推送，這就需要你的監控系統靈活性很高。

還有我們上面說的，自定義采集規則。我認為這個是最重要的原因。不同規則采集到的數據不一樣，因此第三方標準的采集規則可能并不符合你公司的需求。比如有的公司需要獲取設備標識作為唯一 ID，有的公司卻需要用戶標識。這是由業務決定的，每個公司都不一樣。

我司前端組就是自研前端監控平臺。優勢就是可以自定義自己的采集規則，設計自己的數據庫存儲字段，數據都保存在自己的平臺，靈活性和可靠性都非常高，能滿足自己的多樣性需求。

自研前端監控的技術棧

先上結論，我司的前端監控是前端組自己搞的，所以技術棧是 React + Node.js + MongoDB。

這是一個比較常規的技術方案，前端自己搞嘛，所以技術棧都以 JS 為主。同時這也是前端比較能琢磨明白的東西，算是一個標準方案吧。

其中，Node.js 部分我們使用 express 框架寫接口，接口總體分兩大類，就是 寫入 和 查詢統計，作用呢就是前端采集到數據之后，要通過調用接口存儲。之后在監控面板上，也要通過接口將數據查詢展現出來。

接口的背后就是 MongoDB 數據庫，作用就是存儲我們采集到的數據。為什么選擇 MongoDB 呢?最主要的原因就是它的寫入性能非常高，寫入速度非常快。上面我們說，監控系統在采集行為數據的時候，寫入非常頻繁，那么對寫入性能的要求就非常高，反觀查詢反而要求不那么高。

這里也有比較難啃的點，就是采集到大量的數據之后，我們需要各個維度的統計分析。比如：

• 某個時間段用戶的訪問次數和訪問時長排行。
• 某個時間段頁面的訪問頻率和停留時間排行。
• 某個時間段接口報錯的次數以及占比統計。

這些比較復雜的查詢統計，主要用到 MongoDB 的聚合查詢。前端寫個基本的分組統計還行，這類復雜查詢我們就捉襟見肘了。怎么辦呢?我們用很長一段時間啃掉了 MongoDB 聚合查詢的所有文檔，按照需求一個一個找函數，看哪個能實現，幾乎把所有聚合函數都翻了一遍。

接口做完，最后用 React 實現一個管理后臺，將數據以圖表，表格的形式展示出來，就可以實時看到線上產品的使用情況了。

當然還有一步，就是寫一個對接釘釘或企業微信的通知接口，在觸發異常的時候發起通知，讓我們能及時知道異常情況。我們的通知是這樣：

這個信息就能比較全面的看出來是哪里出了問題，如果看更詳細的錯誤再去異常面板去找：

總之首先對接口異常全面監控，確認數據沒問題之后我們再前端去排查，效率提高了，鍋也少背了，這不是兩全其美嗎?

最后我們自研的這個小系統在產品上線后發揮了很大的作用，受到了老板的表揚，這樣讓我們受到了鼓舞，繼續完善它～