前端監控的搭建步驟，別再一頭霧水了！
大家好，我是楊成功。
上一篇介紹了，前端為什么要有監控系統?前端監控系統的意義何在?有小伙伴看完后留言想聽些詳細的實現。那么本篇我們就開始介紹前端監控如何實現。
如果還不明白為什么，搞監控有什么用，建議先看上篇文章：??為什么前端不能沒有監控系統???
在動手實現之前，首先腦子里要有一個整體脈絡，明白搭建前端監控具體的流程步驟有哪些。因為前端監控系統實際上是一個完整的全棧項目，而并不僅僅是前端，甚至主要的實現都是圍繞在 數據方面 的。
當然了，還有一點說明，本篇的實現主要是面對普通業務，面向中小廠自研的方向。
我看過大廠做的監控系統，非常復雜能力也非常強，動不動就是億萬級別的數據，最后整還到了大數據的方向。我只介紹如何實現主要功能，如何解決問題。
前端監控的搭建流程分以下幾個階段：
- 采集階段
- API 階段
- 數據存儲階段
- 查詢統計階段
- 可視化階段
- 報警階段
- 部署階段
下面我就梳理一下每個階段的關鍵實現思路。
采集階段：要采集哪些數據?
做監控的第一步就是采集數據，有了數據才是實現監控的前提。
采集數據的意義就是記錄用戶在使用產品過程中的真實操作，結合上一篇我們的分析，真實操作產生的數據可以分兩大類：異常數據 和 行為數據。
我們先分析一下異常數據。項目中的異常總體可以分為兩大類，一類是前端異常，一類是接口異常。
前端異常
前端異?？偨Y起來大概可以分為：
- 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 接口應用。
作為一名光榮的前端工程師，開發接口，自然要選擇同屬 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 保存，然后就可以登入監控系統查看真實的使用數據了。
當這一部分完成之后，恭喜你，一個小型的前端監控系統就搭建好了。后續可以基于此不斷擴展功能，慢慢讓這個自研的監控系統更加強大。
總結
本篇介紹了前端監控系統的搭建過程，將整體流程劃分為幾個階段，簡述了每個階段要做什么事情，以及關鍵問題是什么，幫你理清搭建監控系統的思路。
