大家好，我是楊成功。
提到監控系統，大部分同學首先想到的是後端監控。很明顯，比如檢測伺服器效能，資料庫效能，API 的訪問流量，以及各種服務的執行情況等等，都與後端息息相關。而前端更多承擔的是 UI 展現的角色，主要關注頁面怎麼排版設計，好像沒什麼需要監測的地方，因此一直以來都沒有涉及到監控的概念。
於是呢大家就一致認為：只要後端穩定可控，應用就是穩定可控的，可實際情況真的是這樣嗎？
近年來，前端發展日益迅猛，得益於 JavaScript 的持續進化和瀏覽器功能的不斷增強，前端能做到的事情越來越多，相應的前端應用的複雜度也越來越高。以前我們壓根不會遇到的問題，現在蹭蹭蹭的一股腦都冒出來了。
舉個例子，小明是個前端程式設計師，有一天使用者反饋某頁面某按鈕點了沒有反應。小明立刻找到那個按鈕，輕輕一點，咦？正常的呀。然後小明又用了幾個不同的賬號測試，依然是正常的。這下可把小明難倒了。
怎麼辦？我相信全天下的前端程式設計師們遇到奇怪問題的反應是一樣的。小明這樣告訴使用者：可能是瀏覽器快取問題，不行強制重新整理一下，或者退出登入試試？ 使用者按照小明的建議操作一番，果然奏效！於是給小明發來了一連串的“感謝 ?”。小明尷尬一笑，連忙回覆“小意思”。
過了兩天，又有一個使用者反饋了同樣的問題。小明又祭出了上面的萬能解決大法，依然奏效。可是問題真的解決了嗎？沒有啊！然而小明嘗試過很多遍都無法復現異常，可能原因有很多，比如：
- 資料問題，可能取不到某個屬性
- 前端問題，JS 程式碼執行異常
- 介面問題，可能介面無響應，或沒有返回預期的值
然而正常情況下是沒有問題的，小明多次測試也都正常，一定是在某種特定場景下才會出現這個問題，但是我們無法判斷，捕捉不到。
像這類 Bug 潛伏在我們的系統中，彷彿地雷一樣，指不定什麼時候就會爆。最尷尬的是即便它爆了我們也很難發現，這就導致我們的“排雷行動”困難重重。
某個陽光明媚的下午，小明坐在馬桶上思考人生。突然腦海中一道靈光閃過，小明想到：“如果在使用者觸發異常的那一刻，系統能自動獲取到異常的資料並儲存起來，然後在後臺的某個地方能看到這些資料，我不就可以立刻找到錯誤原因了嗎？”
小明一拍大腿，對呀！我怎麼沒有早點想到呢？這樣的話，只要發生異常我們就能自動捕獲到異常資料，如果再遇到線上報錯，我們不需要使用者反饋，自己就可以發現，而且能馬上定位錯誤原因，這不是一舉兩得？
我相信許多前端前輩們也曾經被上述的問題所困擾，然後也像小明一樣，慢慢的有了這個思路：“將報錯時的異常資料存下來供後續排查”。在這個思路不斷實踐的過程中，逐漸演變成了今天的前端監控。
當然了，今天的前端監控並不僅僅是監控異常資料，任何有利於產品分析的資料都可以加入監控。所以我認為前端監控，就是指採集使用者使用系統過程中產生的關鍵資料，儲存到資料庫，後續可以查詢和分析，這樣的整套實現就被稱為前端監控系統。
前端監控具體能解決什麼問題？
上面用一個例子推匯出前端監控出現的背景，粗略的說了下它如何追蹤線上報錯問題，大家應該初步瞭解了前端監控的意義。現在我們把目光聚焦在專案上，再詳細探究一下它具體能解決哪些問題。
異常報錯問題
首先就是異常報錯的問題。就如例子中的場景一樣，線上發生異常，有時候我們難以復現，甚至如果沒有使用者反饋，我們都不知道有這個問題，這樣就給使用者傳遞了一種我們的產品很不穩定的感覺。因此前端監控是線上產品穩定和異常及時反饋的非常關鍵的保障。
當然了，除了前端的異常，我們同樣可以捕獲 介面異常。有的時候前端程式設計師們自嘲自己是“背鍋俠”，產品，測試，使用者，遇到問題首先找前端，不管是不是前端的問題，前端先頂，再花時間定位錯誤。有的時候領導脾氣不好，上來先劈頭蓋臉一頓罵，卑微前端也不敢說話，因為啥問題得排查後才清楚，結果排查完後是介面的問題，白捱了一頓罵，心裡就非常不爽。
但是如果有了前端監控，我們就能馬上拿到異常發生時的錯誤資訊，頁面，地址，引數等，什麼問題一查便知。下一次遇到線上事故，前端就可以從容不迫客觀公正的說這是哪一方的問題。如果遇到甩鍋行為，前端也能勇敢說不，畢竟我證據在手，豈容你說吼就吼？
效能檢測問題
追蹤異常是前端監控最實用的地方，但不光如此，效能監控 也是非常關鍵的部分。
當下的前端工程體量很大，如果程式碼質量不高，或者專案架構設計不合理，很容易遇到效能問題。效能問題比如首屏載入時間，頁面是否卡頓，白屏，資源重複請求等，可以通過資料採集，比如計算渲染時間，請求介面數量，請求資源總量等，對某個頁面進行監控，及時發現效能問題。
那麼除了可以“解決問題”，前端監控還有哪些價值？
運營反饋工具
其實前端監控除了可以幫助程式設計師不斷優化和完善應用，對產品和運營同學有同樣不可或缺的作用。具體來說就是通過“埋點監控”來收集使用者的行為資料，則可以對線上產品的使用情況作出統計分析，比如整體的 PV/UV，某個功能的訪問量，訪問時段，點選率等等資料。這些資料可以幫助產品和運營瞭解實際情況，進而改進產品功能。
這些行為資料的收集，可以非常精準的描繪出某個功能或者某個人的實際使用情況。當然採集的資料量也要比異常資料大的多。相比來說，異常監控是隻有發生異常才會收集資料，而行為資料則是，只要使用者使用我們的產品，與產品發生互動，理論上這些資料都要收集起來。
當然監控是多方面的，收集哪些資料視情況而定。總之你想了解產品的任何情況，都可以通過設計採集規則然後收集資料來實現，這方面是非常靈活的，並不僅僅限於大家熟知的那幾個指標。
為什麼要選擇自研？
前端監控發展到現在，必然會有成熟的第三方平臺。目前國內最常用的有三個：
- sentry
- webfunny
- fundebug
首先 sentry 和 fundebug 這兩個平臺是付費的，而且你的資料越多費用越高，相當於是資料託管平臺。webfunny 雖然可以私有化部署，但是它的功能是固定的，沒法改程式碼，這就是它的缺點：不夠靈活，無法定製功能。
所以目前雖然市面上已經有成熟的監控系統，但依然有很多團隊選擇自研。一是資料可以儲存在自己的伺服器上，不用另外花錢；二是靈活性強，可以自定義功能，比如你可以在觸發異常時，接入自己的釘釘或企業微信訊息推送，這就需要你的監控系統靈活性很高。
還有我們上面說的，自定義採集規則。我認為這個是最重要的原因。不同規則採集到的資料不一樣，因此第三方標準的採集規則可能並不符合你公司的需求。比如有的公司需要獲取裝置標識作為唯一 ID，有的公司卻需要使用者標識。這是由業務決定的，每個公司都不一樣。
我司前端組就是自研前端監控平臺。優勢就是可以自定義自己的採集規則，設計自己的資料庫儲存欄位，資料都儲存在自己的平臺，靈活性和可靠性都非常高，能滿足自己的多樣性需求。
自研前端監控的技術棧
先上結論，我司的前端監控是前端組自己搞的，所以技術棧是 React + Node.js + MongoDB。
這是一個比較常規的技術方案，前端自己搞嘛，所以技術棧都以 JS 為主。同時這也是前端比較能琢磨明白的東西，算是一個標準方案吧。
其中，Node.js 部分我們使用 express 框架寫介面，介面總體分兩大類，就是 寫入 和 查詢統計，作用呢就是前端採集到資料之後，要通過呼叫介面儲存。之後在監控面版上，也要通過介面將資料查詢展現出來。
介面的背後就是 MongoDB 資料庫，作用就是儲存我們採集到的資料。為什麼選擇 MongoDB 呢？最主要的原因就是它的寫入效能非常高，寫入速度非常快。上面我們說，監控系統在採集行為資料的時候，寫入非常頻繁，那麼對寫入效能的要求就非常高，反觀查詢反而要求不那麼高。
這裡也有比較難啃的點，就是採集到大量的資料之後，我們需要各個維度的統計分析。比如：
- 某個時間段使用者的訪問次數和訪問時長排行
- 某個時間段頁面的訪問頻率和停留時間排行
- 某個時間段介面報錯的次數以及佔比統計
這些比較複雜的查詢統計，主要用到 MongoDB 的聚合查詢。前端寫個基本的分組統計還行，這類複雜查詢我們就捉襟見肘了。怎麼辦呢？我們用很長一段時間啃掉了 MongoDB 聚合查詢的所有文件，按照需求一個一個找函式，看哪個能實現，幾乎把所有聚合函式都翻了一遍。
介面做完，最後用 React 實現一個管理後臺，將資料以圖表，表格的形式展示出來，就可以實時看到線上產品的使用情況了。
當然還有一步，就是寫一個對接釘釘或企業微信的通知介面，在觸發異常的時候發起通知，讓我們能及時知道異常情況。我們的通知是這樣：
這個資訊就能比較全面的看出來是哪裡出了問題，如果看更詳細的錯誤再去異常皮膚去找：
總之首先對介面異常全面監控，確認資料沒問題之後我們再前端去排查，效率提高了，鍋也少背了，這不是兩全其美嗎？
最後我們自研的這個小系統在產品上線後發揮了很大的作用，受到了老闆的表揚，這樣讓我們受到了鼓舞，繼續完善它～
更多資源
本文來源公眾號 程式設計師成功。作者楊成功，專注於前端工程與架構的分享，關注我檢視更多硬核知識。
本文的任何問題和建議，都歡迎與我溝通，感謝閱讀 ?