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