首頁預覽
背景：入職不久，被要求去電銷群裡解決線上的問題，說都堆了一堆問題了。我一聽，這是要重用我啊，於是乎，摩拳擦掌衝進電銷群裡，準備大幹一場。我向上翻了半個小時的聊天記錄，隱隱感覺到背後有一股涼意，我轉頭看了一眼老大，只見他嘴角上揚，向我致以親切微笑，好像是在說”我相信你能行“，既然這麼被信任我，還有什麼好說的。 好在我們公司也不是什麼小氣的主兒，什麼監控系統都捨得買，光前端相關的監控系統就有仨（當然現在一個都沒有了，因為嫌太貴，啪啪打臉）。正是因為我常遊走於這幾個監控系統之間，所以隱隱感覺到這些監控都有不能夠滿足我的需求。並不是說這些監控系統都不好，畢竟他們都是成名公司的產品，而是因為我想擁有一個屬於自己的監控系統，我想監控什麼就監控什麼，就這麼簡單。
前言：當你開發的項目在線上運行的時候，你能否知道它是否在健康的運行呢？當你的js出現大量報錯，你能及時的知道，並快速的修復嗎？當你的接口出現大量的錯誤導致線上錯誤，你能快速發現並及時甩鍋給後端的小夥伴嗎？當你的CDN嗝屁了，你能知道是運行商的問題，而不是滿頭大汗排查你的代碼嗎？當你線上的用戶在app上做了一大堆奇葩的操作，搞成了一個莫名的Bug，你有信心將它復現嗎？
如果，你還是一位手無寸鐵的前端小白，那我覺得你就太南了，你無法解決以上的任何問題，趕緊去整一個吧，哈哈。 話不多說，看看我們需要做些什麼吧。
=================================
Github搜索：webfunny_monitor ，或者訪問網站：www.webfunny.cn ; 只需要簡單幾步，就可以搭建一套屬於自己的前端監控系統，試試吧。
=================================
功能分析：
- 1. 用戶訪問頁面的監控與上報功能：
記錄用戶訪問頁面的行為；記錄用戶首次訪問頁面的加載時間；可以分析用戶的PV/UV數據、用戶的訪問軌跡、統計頁面加載耗時、評估用戶的網絡環境等。
- 2. Js代碼執行時異常、自定義異常的監控與上報功能：
javascript代碼異常分為執行時異常，自定義異常，第三方異常。我們對其進行分類上報和分析。
- 3. 接口請求（包括成功與失敗狀態，接口請求耗時）的監控與上報功能：
用戶在使用應用的時候，會發生大量的接口請求，接口請求會出現400，500等報錯異常，也會出現耗時過長無法獲取數據，以及接口參數和接口返回結果，我們都會對其進行上報。
- 4. 靜態資源加載日誌的監控與上報功能：
說實話，我們已經不止一次遇到CDN報錯的問題了，靜態資源加載報錯是對用戶使用體驗影響最大的因素，因為會直接導致應用空白而無法使用，這個也是我們需要監控的重點對象。
- 5. 點擊事件日誌的記錄與上報功能：
用戶在應用上最直接的交互行為就是點擊事件，很多異常都是在點擊之後發生，所以需要記錄用戶的點擊行為，才能夠更快速地幫助用戶解決問題。
- 6. 截屏日誌的記錄、錄屏日誌的記錄與上報功能
在將以上的方法都排查過後，依然無法找到原因，我們可以使用JavaScript技術對頁面進行截屏，甚至，我們可以對用戶的頁面進行錄屏，看到用戶是如何使用的，對問題的原因進行查找。
- 7. 用戶行為的記錄與分析：
線上用戶的行為表現多種多樣，有些用戶在應用中的表現超出預期，我們無法通過整體的統計情況來解決問題，這個時候就需要針對具體的用戶進行處理，我們會通過用戶的標識信息查看用戶在應用整個生命週期中的行為，追蹤每一步的具體信息，從而定位出問題所在。
技術工具：
好了，功能分析做完了，我們可是認真的，看看我們需要用到哪些技術和工具來幫我們完成任務。前端監控系統分為三個部分，探針、後端分析服務、數據可視化系統。探針部分使用JavaScript原生代碼編寫，引入html2canvas, rrweb等插件進行截屏和錄屏；後端分析服務採用以nodeJs為基礎的koa2框架搭配mysql5.4進行編寫；數據可視化系統採用的是react全家桶、webpack、es6等技術進行開發。整套系統採用前後分離的架構設計，功能邊界劃分清晰，開發起來非常方便。
系統框架簡圖
流程設計：
- 1. 總流程：
監控系統總流程圖
- 2. 日誌蒐集流程：
日誌蒐集流程圖
探針部署到應用中後，便開始對頁面訪問日誌、JavaScript報錯日誌、接口請求日誌、靜態資源加載日誌、點擊行為日誌、截屏錄屏日誌等進行監聽。一旦獲取到日誌信息，邊通過加密手段進行處理，然後將其儲存在瀏覽器本地緩存中。由於用戶的日誌信息量比較多，所以需要將日誌信息積攢到一定數量之後再進行上傳。所以，會在瀏覽器中定時檢查本地緩存中日誌的數量，達到一定量之後，上傳給後臺的消息隊列。至此，完成了一輪完整的上傳操作。
- 3. 日誌上報流程：
日誌上報流程圖
由於用戶的行為日誌種類比較多，每個用戶都有可能在同一時間產生很多的日誌信息，一但用戶集中訪問我們的應用，就會出現併發問題。比如公司發送推文，做活動的時候，都會出現這種情況。為了解決這個併發問題，我們使用消息隊列的方法來進行削峰填谷，以緩解對服務器造成的壓力。所以前端應用產生的日誌會發送給日誌上報服務器，上報服務器接收到日誌信息後，不會立即存儲到數據庫中，而是將信息存到消息隊列中。與此同時，日誌接收服務也會不停的檢查消息隊列中的消息，一旦檢測到消息內容，就會將隊列中的消息取出，並存放在mysql數據庫中。至此，日誌上報流程就完成了。
- 4. 日誌查詢和分析流程：
日誌查詢和分析流程圖
日誌接收服務從消息隊列中取出日誌信息，並將其分類存入到mysql數據庫以後，接下來由日誌分析服務來完成日誌解析的工作。由於每天每時甚至每分鐘產生的日誌都非常多，所以需要在服務器空閒的時間對數據裡的數據進行分析，日誌分析服務在每天的凌晨對數據進行分析整理，得到可以用於展示的數據結果，在通過數據可視化系統將這些數據結果展現出來。
至此，我們的需求分析做完了。下一章，介紹部署和發佈。
我收到很多小夥伴的留言，有鼓勵我繼續完善的，有讚賞監控系統功能價值的，也有質疑我為什麼要重複造輪子的。對於這些質疑，其實很簡單，作為開發者，不管你想或是不想，線上的問題就擺在那裡，只會多不會少。而這套監控系統切實的幫我解決了現實的問題，幫助我提高了開發的效率，希望它也能幫到你。
閱讀更多 一步一個腳印一個坑 的文章
