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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

異常報(bào)錯(cuò)問題

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

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

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

性能檢測(cè)問題

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

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

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

運(yùn)營反饋工具

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

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

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

為什么要選擇自研?

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

• sentry
• webfunny
• fundebug

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總之首先對(duì)接口異常全面監(jiān)控，確認(rèn)數(shù)據(jù)沒問題之后我們?cè)偾岸巳ヅ挪椋侍岣吡?，鍋也少背了，這不是兩全其美嗎?

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