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

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

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

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

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

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

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

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

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

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

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

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

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

前端監(jiān)控具體能解決什么問題?

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

異常報錯問題

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

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

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

性能檢測問題

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

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

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

運營反饋工具

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

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

當然監(jiān)控是多方面的，收集哪些數(shù)據(jù)視情況而定?？傊阆肓私猱a(chǎn)品的任何情況，都可以通過設(shè)計采集規(guī)則然后收集數(shù)據(jù)來實現(xiàn)，這方面是非常靈活的，并不僅僅限于大家熟知的那幾個指標。

為什么要選擇自研?

前端監(jiān)控發(fā)展到現(xiàn)在，必然會有成熟的第三方平臺。目前國內(nèi)最常用的有三個：

• sentry
• webfunny
• fundebug

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

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

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

我司前端組就是自研前端監(jiān)控平臺。優(yōu)勢就是可以自定義自己的采集規(guī)則，設(shè)計自己的數(shù)據(jù)庫存儲字段，數(shù)據(jù)都保存在自己的平臺，靈活性和可靠性都非常高，能滿足自己的多樣性需求。

自研前端監(jiān)控的技術(shù)棧

先上結(jié)論，我司的前端監(jiān)控是前端組自己搞的，所以技術(shù)棧是 React + Node.js + MongoDB。

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

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

接口的背后就是 MongoDB 數(shù)據(jù)庫，作用就是存儲我們采集到的數(shù)據(jù)。為什么選擇 MongoDB 呢?最主要的原因就是它的寫入性能非常高，寫入速度非?？臁Ｉ厦嫖覀冋f，監(jiān)控系統(tǒng)在采集行為數(shù)據(jù)的時候，寫入非常頻繁，那么對寫入性能的要求就非常高，反觀查詢反而要求不那么高。

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

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

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

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

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

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

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

最后我們自研的這個小系統(tǒng)在產(chǎn)品上線后發(fā)揮了很大的作用，受到了老板的表揚，這樣讓我們受到了鼓舞，繼續(xù)完善它～