前端監控的搭建步驟，別再一頭霧水了！

大家好，我是楊成功。

上一篇介紹了，前端為什麼要有監控系統？前端監控系統的意義何在？有小夥伴看完後留言想聽些詳細的實現。那麼本篇我們就開始介紹前端監控如何實現。

如果還不明白為什麼，搞監控有什麼用，建議先看上篇文章： 為什麼前端不能沒有監控系統？

在動手實現之前，首先腦子裡要有一個整體脈絡，明白搭建前端監控具體的流程步驟有哪些。因為前端監控系統實際上是一個完整的全棧專案，而並不僅僅是前端，甚至主要的實現都是圍繞在資料方面的。

當然了，還有一點說明，本篇的實現主要是面對普通業務，面向中小廠自研的方向。我看過大廠做的監控系統，非常複雜能力也非常強，動不動就是億萬級別的資料，最後整還到了大資料的方向。我只介紹如何實現主要功能，如何解決問題。

前端監控的搭建流程分以下幾個階段：

1. 採集階段：資料的採集
2. API 階段：搭建 API 應用，接收採集到的資料
3. 資料儲存階段：API 應用對接資料庫，將採集到的資料存起來
4. 查詢統計階段：對採集到的資料進行查詢，統計，分析
5. 視覺化階段：前端通過 API 查詢統計資料，做視覺化展示
6. 報警階段：API 對接報警通知服務，如釘釘
7. 部署階段：應用整體部署上線

下面我就梳理一下每個階段的關鍵實現思路。

採集階段：要採集哪些資料？

做監控的第一步就是採集資料，有了資料才是實現監控的前提。

採集資料的意義就是記錄使用者在使用產品過程中的真實操作，結合上一篇我們的分析，真實操作產生的資料可以分兩大類：

1. 異常資料
2. 行為資料

我們先分析一下異常資料。專案中的異常總體可以分為兩大類，一類是 前端異常 ，一類是 介面異常 。 前端異常 總結起來大概分為：

• js 程式碼執行異常
• Promise 異常
• 靜態資源載入異常
• console.error 異常
• 跨域異常

其中最重要的，也是我們遇到最多的，就是各種各樣的 js 程式碼執行異常。比如型別錯誤，引用錯誤等等，這些異常大多是我們編碼不嚴謹導致的，因此收集此類異常有利於我們改進編碼質量。

然後就是 Promise 異常，Promise 是 ES6 最重要的屬性之一，考驗我們的 js 非同步程式設計能力，集中體現在介面請求上面，因此這兩部分的異常捕獲非常關鍵。

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

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

至於跨域異常，這個我們常常碰到，一般在前後端開發時的聯調階段就能發現。不過也保不定後端在線上突然改了什麼配置，導致前端跨域，為了安全這個也要監聽一下。

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

介面異常屬於後端的異常，但是介面異常會直接導致前端頁面錯誤，因此這類異常是我們判斷線上問題根源的重要依據。介面異常可以根據響應結果分類：

• 未響應/超時響應異常
• 4xx 請求異常
• 5xx 伺服器異常
• 許可權不足

有時候因為網路問題或者伺服器問題，前端在發起請求之後遲遲未收到響應，請求被掛起，這種時候就屬於未響應/超時響應異常。這類異常我們可以設定最大請求時間，超時之後主動斷開請求，並新增一條介面超時記錄。

除此之外，其他型別的介面異常我們就可以根據 HTTP 狀態碼 或者後端返回的指定欄位如 error_code 來判斷。

不管是用狀態碼還是其他判斷方式，只要能區分異常型別就可以，這個不做嚴格要求。

4xx異常型別是請求異常，一般是前端傳遞的引數問題，或者介面驗證引數的問題。處理這類異常的關鍵是儲存請求引數，可以方便前端排錯。

5xx錯誤是伺服器內部處理的異常，這類異常的關鍵資訊是報錯時間，以及返回的異常說明，將這些儲存下來，可以方便後端去查詢日誌。

許可權不足我覺得也是一類重要的錯誤。因為現在某些管理系統的許可權設計比較複雜，有時候突然莫名其妙的介面調不通，影響使用者的下一步操作，這也需要記錄和追蹤。

雖然這裡只列出了最通用三類，但是自研監控系統的一大優點就是靈活。如果你的業務場景有更復雜的異常情況，那麼你完全可以自由發揮，從自己業務的實際情況出發，設計出更適合自己的異常分類，只要終極目標是可以幫我們更好的追蹤和快速解決問題就可以。

這個階段非常關鍵，是監控系統設計的核心，所以我寫的比較細，大家在這個階段關於採集哪些資料也要多多考慮。而後面的階段，則都是基於此設計的具體實現。

API 階段：搭建上報資料的 API 介面

上一階段做好了採集資料的方案，當採集到資料之後，接下來就要將 資料上報 。

資料上報說白了就是通過呼叫一個 API 介面將這些資料傳過去然後存在資料庫中，因此本階段的任務就是搭建上報資料的 API 介面應用。

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

搭建 API 應用要做的事情有：

• 目錄結構設計
• 路由設計
• 鑑權認證
• 引數驗證
• 請求響應封裝
• 錯誤處理

還有一些細節的處理。這個階段對後端基礎薄弱的同學來說，是非常好的學習時機。

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

框架搭好之後，主要做的就是設計介面 URL 然後寫處理邏輯，保證這一步設計的介面能調通，並且能接收到資料。

資料儲存階段：介面對接資料庫

上一步我們搭建好了 API 介面，接收到了採集的資料，那麼我們這一步就是要對接資料庫，將採集到的資料存到資料庫裡。

資料庫的話，就選對前端最友好的，屬於 NoSQL 家族的文件資料庫 MongoDB 。

這個資料庫最大的特點是，儲存的資料格式類似於 JSON，操作起來就像在 JS 中呼叫函式，組合 JOSN 資料一樣，對我們前端理解和入門非常容易，在實戰過程中你就能體會到它的優雅了。

資料儲存階段，主要介紹資料庫的基本資訊和操作，包括以下方面：

• 資料庫怎麼連線
• 怎麼設計欄位
• 怎麼做驗證
• 怎麼寫入
• 怎麼查詢

這個階段比較關鍵的是 資料驗證 ，在設計好資料庫欄位之後，我們希望所有寫入的資料都要符合我們想要的資料格式。如果在驗證之後不符合，我們可以補充或修改資料欄位，或者直接拒絕寫入，這樣能保證資料的可靠性，也避免了不必要的資料清理。

做好了資料寫入的工作，還要加一部分簡單的查詢和修改功能。因為你寫入資料之後要看看執行成功沒有，就可以查一個列表看結果了。

修改功能也很必要。前端監控中有一個很常見的需求是： 計算使用者的頁面停留時間 。我的方案是在使用者進入某個頁面的時候建立一條記錄，然後在離開時，修改這條記錄，加一個結束時間的欄位，這就需要修改功能了。

最後還要提一下，很多人在聊怎麼做 資料清洗 。其實這個就看你前面儲存資料的時候驗證做的怎麼樣了。如果確實有可能存入無效的資料，那麼就可以寫一個清除資料的介面，寫自己的清理邏輯，然後定時執行一下。

查詢統計階段：資料查詢和統計分析

前面經過一系列準備我們完成了 API 介面和資料寫入的功能，假設我們已經採集到了足夠的資料並存入資料庫，這個階段就是好好利用這些資料的時候了。

本階段的主要任務就是對資料進行檢索和 統計分析 ，基本上都是“查詢”的操作。

這裡的查詢不單單只是查一下，具體怎麼查，關係到了我們蒐集的資料能否有效利用。我的思路還是從這兩個方面入手：

行為資料
異常資料

當然了這只是從總體來說。行為資料也會單條查詢，比如我要看某個時間某個使用者做了什麼操作，這就屬於精確查詢。異常資料也有統計，比如異常介面觸發頻率的排行等。

行為資料的資料量會非常大，在使用者使用系統的過程中會頻繁產生然後頻繁被寫入資料庫。因此這類資料絕大多數情況是通過 聚合查詢 的方式從頁面，時間等多個維度做總體統計，最後得出一些百分比的結論。這些統計值可以大致反應出產品的實際使用情況。

這裡有個優化點，因為頻繁請求會加重介面負擔，因此資料也可以本地先儲存一部分，達到一定量之後再請求介面，一次性存入。

異常資料對開發人員來說非常重要，是我們定位和解決 bug 的神輔助。不同於行為資料的多條統計，異常資料我們更關心單獨每一條記錄的詳細資訊，方便我們一目瞭然的看到錯誤。

異常資料查詢也比較簡單，和普通的列表查詢一樣，返回最新的異常資料即可。當然了我們排查問題之後，還應該對處理好的異常標記為已處理，這樣可以防止重複排查。

可以看出，這個階段最主要的還是做統計介面，為下個階段視覺化圖表展示做準備。

視覺化階段：最終的資料圖表展現

上一個階段我們開發了統計介面，查出了想要的資料結果，可惜這些結果只能程式設計師看懂，別人恐怕是看不懂。所以最終為了更直觀的反應資料，我們要用前端視覺化圖表的方式，讓這些資料活起來。

在這個階段，我們終於回到了最熟悉的前端領域。那本階段的任務相對來說也簡單順手，基於 React 搭建一個新的前端應用，接入上一步的統計介面，再整合前端圖表庫，將統計結果用圖表展現出來。

這個新應用是真正要對外展示的前端監控系統，給團隊內部的開發或產品同學使用，這樣他們可以實時檢視產品生成的資料資訊，從而解決自己的問題了。

這一階段其實沒什麼關鍵問題要講，主要就是選擇一個好用的圖表庫，對接介面。還有圖表的種類多種多樣，要考慮哪些資料適合哪種圖表，結合實際判斷一下。

最後，監控系統的前端頁面和介面資料肯定不能所有人都看，所以還要有基礎的登入頁面和功能。做到這裡，本階段的任務就結束了。

報警階段：發現異常馬上報警通知

上一階段，監控系統前端搭建完成，並將統計資料展現為圖表之後，整個監控系統就基本可用了。

但是還有一種情況，就是使用者使用我們的產品突然報錯了，錯誤資訊也被寫入了資料庫。如果此時你沒有主動重新整理頁面，事實上你也不可能一直重新整理，那麼這條錯誤我們是根本不知道的。

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

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

報警通知，一般現在通用的方案是對接釘釘或者是企業微信的機器人，我們這裡使用釘釘。具體用哪個平臺還得看你的主體在哪個平臺。比如我的團隊的主體在釘釘，那麼在傳送報警通知時，可以直接用手機號來 @ 你的任意組員，實現更精準的提醒。

這一部分是 API 應用的補充，申請釘釘開發者許可權之後，在 API 中接入相關程式碼。

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

前面的幾個階段，我們完成了資料採集，API 應用搭建，資料儲存，前端視覺化展現，以及監控報警，整個前端監控系統的功能就全部完備了。最後一步就是將前後端資料庫全部部署上線，供大家訪問。

部署這塊主要是 nginx 解析，https 配置，資料庫安裝，和 nodejs 的應用部署等，這個階段的內容會偏運維一些。不過別擔心，這裡我也會對關鍵操作做詳細介紹。

當這個系統上線以後，你就可以嘗試在你的任意一個前端專案，根據第一篇的採集方法，將採集到的資料通過 API 儲存，然後就可以登入監控系統檢視真實的使用資料了。

當這一部分完成之後，恭喜你，一個小型的前端監控系統就搭建好了。後續可以基於此不斷擴充套件功能，慢慢讓這個自研的監控系統更加強大。

總結

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

下一篇就可以介紹前端監控的實現程式碼了。文章首發公眾號程式設計師成功。作者楊成功，專注於前端工程與架構的分享，關注我檢視更多硬核知識。

本文的任何問題和建議，都歡迎與我溝通，感謝閱讀 :pray: