在動手實現(xiàn)之前，首先腦子里要有一個整體脈絡(luò)，明白搭建前端監(jiān)控具體的流程步驟有哪些。因為前端監(jiān)控系統(tǒng)實際上是一個完整的全棧項目，而并不僅僅是前端，甚至主要的實現(xiàn)都是圍繞在數(shù)據(jù)方面的。

當(dāng)然了，還有一點說明，本篇的實現(xiàn)主要是面對普通業(yè)務(wù)，面向中小廠自研的方向。我看過大廠做的監(jiān)控系統(tǒng)，非常復(fù)雜能力也非常強(qiáng)，動不動就是億萬級別的數(shù)據(jù)，最后整還到了大數(shù)據(jù)的方向。我只介紹如何實現(xiàn)主要功能，如何解決問題。

前端監(jiān)控的搭建流程分以下幾個階段：

1. 采集階段：數(shù)據(jù)的采集
2. API 階段：搭建 API 應(yīng)用，接收采集到的數(shù)據(jù)
3. 數(shù)據(jù)存儲階段：API 應(yīng)用對接數(shù)據(jù)庫，將采集到的數(shù)據(jù)存起來
4. 查詢統(tǒng)計階段：對采集到的數(shù)據(jù)進(jìn)行查詢，統(tǒng)計，分析
5. 可視化階段：前端通過 API 查詢統(tǒng)計數(shù)據(jù)，做可視化展示
6. 報警階段：API 對接報警通知服務(wù)，如釘釘
7. 部署階段：應(yīng)用整體部署上線

下面我就梳理一下每個階段的關(guān)鍵實現(xiàn)思路。

采集階段：要采集哪些數(shù)據(jù)？

做監(jiān)控的第一步就是采集數(shù)據(jù)，有了數(shù)據(jù)才是實現(xiàn)監(jiān)控的前提。

采集數(shù)據(jù)的意義就是記錄用戶在使用產(chǎn)品過程中的真實操作，結(jié)合上一篇我們的分析，真實操作產(chǎn)生的數(shù)據(jù)可以分兩大類：

1. 異常數(shù)據(jù)
2. 行為數(shù)據(jù)

我們先分析一下異常數(shù)據(jù)。項目中的異常總體可以分為兩大類，一類是 前端異常 ，一類是 接口異常 。 前端異常 總結(jié)起來大概分為：

• js 代碼執(zhí)行異常
• Promise 異常
• 靜態(tài)資源加載異常
• console.error 異常
• 跨域異常

其中最重要的，也是我們遇到最多的，就是各種各樣的 js 代碼執(zhí)行異常。比如類型錯誤，引用錯誤等等，這些異常大多是我們編碼不嚴(yán)謹(jǐn)導(dǎo)致的，因此收集此類異常有利于我們改進(jìn)編碼質(zhì)量。

然后就是 Promise 異常，Promise 是 ES6 最重要的屬性之一，考驗我們的 js 異步編程能力，集中體現(xiàn)在接口請求上面，因此這兩部分的異常捕獲非常關(guān)鍵。

除此之外，靜態(tài)資源加載異常，一般指在 html 中引用一些圖片地址，第三方 js 地址等，各種原因不能正常加載了，這個也要監(jiān)聽的到。

console.error 異常，一般是在用某個第三方前端框架，他里面自定義了一些錯誤，會用 console.error 拋出來，這類異常也有捕獲的必要性。

至于跨域異常，這個我們常常碰到，一般在前后端開發(fā)時的聯(lián)調(diào)階段就能發(fā)現(xiàn)。不過也保不定后端在線上突然改了什么配置，導(dǎo)致前端跨域，為了安全這個也要監(jiān)聽一下。

前端的異常采集大概就這 5 種吧，基本囊括了前端 90% 以上的異常情況。

接口異常屬于后端的異常，但是接口異常會直接導(dǎo)致前端頁面錯誤，因此這類異常是我們判斷線上問題根源的重要依據(jù)。接口異?？梢愿鶕?jù)響應(yīng)結(jié)果分類：

• 未響應(yīng)/超時響應(yīng)異常
• 4xx 請求異常
• 5xx 服務(wù)器異常
• 權(quán)限不足

有時候因為網(wǎng)絡(luò)問題或者服務(wù)器問題，前端在發(fā)起請求之后遲遲未收到響應(yīng)，請求被掛起，這種時候就屬于未響應(yīng)/超時響應(yīng)異常。這類異常我們可以設(shè)置最大請求時間，超時之后主動斷開請求，并添加一條接口超時記錄。

除此之外，其他類型的接口異常我們就可以根據(jù) HTTP 狀態(tài)碼 或者后端返回的指定字段如 error_code 來判斷。

不管是用狀態(tài)碼還是其他判斷方式，只要能區(qū)分異常類型就可以，這個不做嚴(yán)格要求。

4xx異常類型是請求異常，一般是前端傳遞的參數(shù)問題，或者接口驗證參數(shù)的問題。處理這類異常的關(guān)鍵是保存請求參數(shù)，可以方便前端排錯。

5xx錯誤是服務(wù)器內(nèi)部處理的異常，這類異常的關(guān)鍵信息是報錯時間，以及返回的異常說明，將這些保存下來，可以方便后端去查找日志。

權(quán)限不足我覺得也是一類重要的錯誤。因為現(xiàn)在某些管理系統(tǒng)的權(quán)限設(shè)計比較復(fù)雜，有時候突然莫名其妙的接口調(diào)不通，影響用戶的下一步操作，這也需要記錄和追蹤。

雖然這里只列出了最通用三類，但是自研監(jiān)控系統(tǒng)的一大優(yōu)點就是靈活。如果你的業(yè)務(wù)場景有更復(fù)雜的異常情況，那么你完全可以自由發(fā)揮，從自己業(yè)務(wù)的實際情況出發(fā)，設(shè)計出更適合自己的異常分類，只要終極目標(biāo)是可以幫我們更好的追蹤和快速解決問題就可以。

這個階段非常關(guān)鍵，是監(jiān)控系統(tǒng)設(shè)計的核心，所以我寫的比較細(xì)，大家在這個階段關(guān)于采集哪些數(shù)據(jù)也要多多考慮。而后面的階段，則都是基于此設(shè)計的具體實現(xiàn)。

API 階段：搭建上報數(shù)據(jù)的 API 接口

上一階段做好了采集數(shù)據(jù)的方案，當(dāng)采集到數(shù)據(jù)之后，接下來就要將 數(shù)據(jù)上報 。

數(shù)據(jù)上報說白了就是通過調(diào)用一個 API 接口將這些數(shù)據(jù)傳過去然后存在數(shù)據(jù)庫中，因此本階段的任務(wù)就是搭建上報數(shù)據(jù)的 API 接口應(yīng)用。

作為一名光榮的前端工程師，開發(fā)接口，自然要選擇同屬 JS 家族的 Node.js 了。Node.js 目前的框架也比較多，我比較喜歡輕量好簡潔的，需要什么自己安裝，所以我選擇簡單經(jīng)典的 Express 框架。

搭建 API 應(yīng)用要做的事情有：

• 目錄結(jié)構(gòu)設(shè)計
• 路由設(shè)計
• 鑒權(quán)認(rèn)證
• 參數(shù)驗證
• 請求響應(yīng)封裝
• 錯誤處理

還有一些細(xì)節(jié)的處理。這個階段對后端基礎(chǔ)薄弱的同學(xué)來說，是非常好的學(xué)習(xí)時機(jī)。

我非常建議前端小伙伴們掌握一部分后端基本知識，至少在簡單的原理方面明白是怎么回事。這個階段主要是搞明白 API 應(yīng)用是怎么搭建起來的，每個部分為什么要這么做，能解決什么問題，這樣你的后端基礎(chǔ)知識就會建立起來了。

框架搭好之后，主要做的就是設(shè)計接口 URL 然后寫處理邏輯，保證這一步設(shè)計的接口能調(diào)通，并且能接收到數(shù)據(jù)。

數(shù)據(jù)存儲階段：接口對接數(shù)據(jù)庫

上一步我們搭建好了 API 接口，接收到了采集的數(shù)據(jù)，那么我們這一步就是要對接數(shù)據(jù)庫，將采集到的數(shù)據(jù)存到數(shù)據(jù)庫里。

數(shù)據(jù)庫的話，就選對前端最友好的，屬于 NoSQL 家族的文檔數(shù)據(jù)庫 MongoDB 。

這個數(shù)據(jù)庫最大的特點是，存儲的數(shù)據(jù)格式類似于 JSON，操作起來就像在 JS 中調(diào)用函數(shù)，組合 JOSN 數(shù)據(jù)一樣，對我們前端理解和入門非常容易，在實戰(zhàn)過程中你就能體會到它的優(yōu)雅了。

數(shù)據(jù)存儲階段，主要介紹數(shù)據(jù)庫的基本信息和操作，包括以下方面：

• 數(shù)據(jù)庫怎么連接
• 怎么設(shè)計字段
• 怎么做驗證
• 怎么寫入
• 怎么查詢

這個階段比較關(guān)鍵的是 數(shù)據(jù)驗證 ，在設(shè)計好數(shù)據(jù)庫字段之后，我們希望所有寫入的數(shù)據(jù)都要符合我們想要的數(shù)據(jù)格式。如果在驗證之后不符合，我們可以補(bǔ)充或修改數(shù)據(jù)字段，或者直接拒絕寫入，這樣能保證數(shù)據(jù)的可靠性，也避免了不必要的數(shù)據(jù)清理。

做好了數(shù)據(jù)寫入的工作，還要加一部分簡單的查詢和修改功能。因為你寫入數(shù)據(jù)之后要看看執(zhí)行成功沒有，就可以查一個列表看結(jié)果了。

修改功能也很必要。前端監(jiān)控中有一個很常見的需求是： 計算用戶的頁面停留時間 。我的方案是在用戶進(jìn)入某個頁面的時候創(chuàng)建一條記錄，然后在離開時，修改這條記錄，加一個結(jié)束時間的字段，這就需要修改功能了。

最后還要提一下，很多人在聊怎么做 數(shù)據(jù)清洗 。其實這個就看你前面存儲數(shù)據(jù)的時候驗證做的怎么樣了。如果確實有可能存入無效的數(shù)據(jù)，那么就可以寫一個清除數(shù)據(jù)的接口，寫自己的清理邏輯，然后定時執(zhí)行一下。

查詢統(tǒng)計階段：數(shù)據(jù)查詢和統(tǒng)計分析

前面經(jīng)過一系列準(zhǔn)備我們完成了 API 接口和數(shù)據(jù)寫入的功能，假設(shè)我們已經(jīng)采集到了足夠的數(shù)據(jù)并存入數(shù)據(jù)庫，這個階段就是好好利用這些數(shù)據(jù)的時候了。

本階段的主要任務(wù)就是對數(shù)據(jù)進(jìn)行檢索和 統(tǒng)計分析 ，基本上都是“查詢”的操作。

這里的查詢不單單只是查一下，具體怎么查，關(guān)系到了我們搜集的數(shù)據(jù)能否有效利用。我的思路還是從這兩個方面入手：

1. 行為數(shù)據(jù)
2. 異常數(shù)據(jù)

當(dāng)然了這只是從總體來說。行為數(shù)據(jù)也會單條查詢，比如我要看某個時間某個用戶做了什么操作，這就屬于精確查找。異常數(shù)據(jù)也有統(tǒng)計，比如異常接口觸發(fā)頻率的排行等。

行為數(shù)據(jù)的數(shù)據(jù)量會非常大，在用戶使用系統(tǒng)的過程中會頻繁產(chǎn)生然后頻繁被寫入數(shù)據(jù)庫。因此這類數(shù)據(jù)絕大多數(shù)情況是通過 聚合查詢 的方式從頁面，時間等多個維度做總體統(tǒng)計，最后得出一些百分比的結(jié)論。這些統(tǒng)計值可以大致反應(yīng)出產(chǎn)品的實際使用情況。

這里有個優(yōu)化點，因為頻繁請求會加重接口負(fù)擔(dān)，因此數(shù)據(jù)也可以本地先存儲一部分，達(dá)到一定量之后再請求接口，一次性存入。

異常數(shù)據(jù)對開發(fā)人員來說非常重要，是我們定位和解決 bug 的神輔助。不同于行為數(shù)據(jù)的多條統(tǒng)計，異常數(shù)據(jù)我們更關(guān)心單獨每一條記錄的詳細(xì)信息，方便我們一目了然的看到錯誤。

異常數(shù)據(jù)查詢也比較簡單，和普通的列表查詢一樣，返回最新的異常數(shù)據(jù)即可。當(dāng)然了我們排查問題之后，還應(yīng)該對處理好的異常標(biāo)記為已處理，這樣可以防止重復(fù)排查。

可以看出，這個階段最主要的還是做統(tǒng)計接口，為下個階段可視化圖表展示做準(zhǔn)備。

可視化階段：最終的數(shù)據(jù)圖表展現(xiàn)

上一個階段我們開發(fā)了統(tǒng)計接口，查出了想要的數(shù)據(jù)結(jié)果，可惜這些結(jié)果只能程序員看懂，別人恐怕是看不懂。所以最終為了更直觀的反應(yīng)數(shù)據(jù)，我們要用前端可視化圖表的方式，讓這些數(shù)據(jù)活起來。

在這個階段，我們終于回到了最熟悉的前端領(lǐng)域。那本階段的任務(wù)相對來說也簡單順手，基于 React 搭建一個新的前端應(yīng)用，接入上一步的統(tǒng)計接口，再集成前端圖表庫，將統(tǒng)計結(jié)果用圖表展現(xiàn)出來。

這個新應(yīng)用是真正要對外展示的前端監(jiān)控系統(tǒng)，給團(tuán)隊內(nèi)部的開發(fā)或產(chǎn)品同學(xué)使用，這樣他們可以實時查看產(chǎn)品生成的數(shù)據(jù)信息，從而解決自己的問題了。

這一階段其實沒什么關(guān)鍵問題要講，主要就是選擇一個好用的圖表庫，對接接口。還有圖表的種類多種多樣，要考慮哪些數(shù)據(jù)適合哪種圖表，結(jié)合實際判斷一下。

最后，監(jiān)控系統(tǒng)的前端頁面和接口數(shù)據(jù)肯定不能所有人都看，所以還要有基礎(chǔ)的登錄頁面和功能。做到這里，本階段的任務(wù)就結(jié)束了。

報警階段：發(fā)現(xiàn)異常馬上報警通知

上一階段，監(jiān)控系統(tǒng)前端搭建完成，并將統(tǒng)計數(shù)據(jù)展現(xiàn)為圖表之后，整個監(jiān)控系統(tǒng)就基本可用了。

但是還有一種情況，就是用戶使用我們的產(chǎn)品突然報錯了，錯誤信息也被寫入了數(shù)據(jù)庫。如果此時你沒有主動刷新頁面，事實上你也不可能一直刷新，那么這條錯誤我們是根本不知道的。

如果這是一個很致命的 bug，影響很廣泛，Bug 發(fā)生我們竟然不知道，這就會給我們造成很大的損失。

所以呢，為了保證我們及時的解決 Bug，一個報警通知的功能就非常重要了。它的作用是在異常發(fā)生時，第一時間推送給開發(fā)人員，這樣大家才能立即發(fā)現(xiàn)問題，然后用最快的速度去解決，避免遺漏。

報警通知，一般現(xiàn)在通用的方案是對接釘釘或者是企業(yè)微信的機(jī)器人，我們這里使用釘釘。具體用哪個平臺還得看你的主體在哪個平臺。比如我的團(tuán)隊的主體在釘釘，那么在發(fā)送報警通知時，可以直接用手機(jī)號來 @ 你的任意組員，實現(xiàn)更精準(zhǔn)的提醒。

這一部分是 API 應(yīng)用的補(bǔ)充，申請釘釘開發(fā)者權(quán)限之后，在 API 中接入相關(guān)代碼。

部署階段：萬事俱備只等上線

前面的幾個階段，我們完成了數(shù)據(jù)采集，API 應(yīng)用搭建，數(shù)據(jù)存儲，前端可視化展現(xiàn)，以及監(jiān)控報警，整個前端監(jiān)控系統(tǒng)的功能就全部完備了。最后一步就是將前后端數(shù)據(jù)庫全部部署上線，供大家訪問。

部署這塊主要是 nginx 解析，https 配置，數(shù)據(jù)庫安裝，和 nodejs 的應(yīng)用部署等，這個階段的內(nèi)容會偏運維一些。不過別擔(dān)心，這里我也會對關(guān)鍵操作做詳細(xì)介紹。

當(dāng)這個系統(tǒng)上線以后，你就可以嘗試在你的任意一個前端項目，根據(jù)第一篇的采集方法，將采集到的數(shù)據(jù)通過 API 保存，然后就可以登入監(jiān)控系統(tǒng)查看真實的使用數(shù)據(jù)了。

當(dāng)這一部分完成之后，恭喜你，一個小型的前端監(jiān)控系統(tǒng)就搭建好了。后續(xù)可以基于此不斷擴(kuò)展功能，慢慢讓這個自研的監(jiān)控系統(tǒng)更加強(qiáng)大。

總結(jié)

本篇介紹了前端監(jiān)控系統(tǒng)的搭建過程，將整體流程劃分為幾個階段，簡述了每個階段要做什么事情，以及關(guān)鍵問題是什么，幫你理清搭建監(jiān)控系統(tǒng)的思路。