為什麼前端不能沒有監控系統?

語言: CN / TW / HK

大家好,我是楊成功。

提到監控系統,大部分同學首先想到的是後端監控。很明顯,比如檢測伺服器效能,資料庫效能,API 的訪問流量,以及各種服務的執行情況等等,都與後端息息相關。而前端更多承擔的是 UI 展現的角色,主要關注頁面怎麼排版設計,好像沒什麼需要監測的地方,因此一直以來都沒有涉及到監控的概念。

於是呢大家就一致認為:只要後端穩定可控,應用就是穩定可控的,可實際情況真的是這樣嗎?

近年來,前端發展日益迅猛,得益於 JavaScript 的持續進化和瀏覽器功能的不斷增強,前端能做到的事情越來越多,相應的前端應用的複雜度也越來越高。以前我們壓根不會遇到的問題,現在蹭蹭蹭的一股腦都冒出來了。

舉個例子,小明是個前端程式設計師,有一天使用者反饋某頁面某按鈕點了沒有反應。小明立刻找到那個按鈕,輕輕一點,咦?正常的呀。然後小明又用了幾個不同的賬號測試,依然是正常的。這下可把小明難倒了。

怎麼辦?我相信全天下的前端程式設計師們遇到奇怪問題的反應是一樣的。小明這樣告訴使用者:可能是瀏覽器快取問題,不行強制重新整理一下,或者退出登入試試? 使用者按照小明的建議操作一番,果然奏效!於是給小明發來了一連串的“感謝 🙏”。小明尷尬一笑,連忙回覆“小意思”。

過了兩天,又有一個使用者反饋了同樣的問題。小明又祭出了上面的萬能解決大法,依然奏效。可是問題真的解決了嗎?沒有啊!然而小明嘗試過很多遍都無法復現異常,可能原因有很多,比如:

  1. 資料問題,可能取不到某個屬性
  2. 前端問題,JS 程式碼執行異常
  3. 介面問題,可能介面無響應,或沒有返回預期的值

然而正常情況下是沒有問題的,小明多次測試也都正常,一定是在某種特定場景下才會出現這個問題,但是我們無法判斷,捕捉不到。

像這類 Bug 潛伏在我們的系統中,彷彿地雷一樣,指不定什麼時候就會爆。最尷尬的是即便它爆了我們也很難發現,這就導致我們的“排雷行動”困難重重。

某個陽光明媚的下午,小明坐在馬桶上思考人生。突然腦海中一道靈光閃過,小明想到:“如果在使用者觸發異常的那一刻,系統能自動獲取到異常的資料並儲存起來,然後在後臺的某個地方能看到這些資料,我不就可以立刻找到錯誤原因了嗎?”

小明一拍大腿,對呀!我怎麼沒有早點想到呢?這樣的話,只要發生異常我們就能自動捕獲到異常資料,如果再遇到線上報錯,我們不需要使用者反饋,自己就可以發現,而且能馬上定位錯誤原因,這不是一舉兩得?

我相信許多前端前輩們也曾經被上述的問題所困擾,然後也像小明一樣,慢慢的有了這個思路:“將報錯時的異常資料存下來供後續排查”。在這個思路不斷實踐的過程中,逐漸演變成了今天的前端監控。

當然了,今天的前端監控並不僅僅是監控異常資料,任何有利於產品分析的資料都可以加入監控。所以我認為前端監控,就是指採集使用者使用系統過程中產生的關鍵資料,儲存到資料庫,後續可以查詢和分析,這樣的整套實現就被稱為前端監控系統。

前端監控具體能解決什麼問題?

上面用一個例子推匯出前端監控出現的背景,粗略的說了下它如何追蹤線上報錯問題,大家應該初步瞭解了前端監控的意義。現在我們把目光聚焦在專案上,再詳細探究一下它具體能解決哪些問題。

異常報錯問題

首先就是異常報錯的問題。就如例子中的場景一樣,線上發生異常,有時候我們難以復現,甚至如果沒有使用者反饋,我們都不知道有這個問題,這樣就給使用者傳遞了一種我們的產品很不穩定的感覺。因此前端監控是線上產品穩定和異常及時反饋的非常關鍵的保障。

當然了,除了前端的異常,我們同樣可以捕獲 介面異常。有的時候前端程式設計師們自嘲自己是“背鍋俠”,產品,測試,使用者,遇到問題首先找前端,不管是不是前端的問題,前端先頂,再花時間定位錯誤。有的時候領導脾氣不好,上來先劈頭蓋臉一頓罵,卑微前端也不敢說話,因為啥問題得排查後才清楚,結果排查完後是介面的問題,白捱了一頓罵,心裡就非常不爽。

但是如果有了前端監控,我們就能馬上拿到異常發生時的錯誤資訊,頁面,地址,引數等,什麼問題一查便知。下一次遇到線上事故,前端就可以從容不迫客觀公正的說這是哪一方的問題。如果遇到甩鍋行為,前端也能勇敢說不,畢竟我證據在手,豈容你說吼就吼?

效能檢測問題

追蹤異常是前端監控最實用的地方,但不光如此,效能監控 也是非常關鍵的部分。

當下的前端工程體量很大,如果程式碼質量不高,或者專案架構設計不合理,很容易遇到效能問題。效能問題比如首屏載入時間,頁面是否卡頓,白屏,資源重複請求等,可以通過資料採集,比如計算渲染時間,請求介面數量,請求資源總量等,對某個頁面進行監控,及時發現效能問題。

那麼除了可以“解決問題”,前端監控還有哪些價值?

運營反饋工具

其實前端監控除了可以幫助程式設計師不斷優化和完善應用,對產品和運營同學有同樣不可或缺的作用。具體來說就是通過“埋點監控”來收集使用者的行為資料,則可以對線上產品的使用情況作出統計分析,比如整體的 PV/UV,某個功能的訪問量,訪問時段,點選率等等資料。這些資料可以幫助產品和運營瞭解實際情況,進而改進產品功能。

這些行為資料的收集,可以非常精準的描繪出某個功能或者某個人的實際使用情況。當然採集的資料量也要比異常資料大的多。相比來說,異常監控是隻有發生異常才會收集資料,而行為資料則是,只要使用者使用我們的產品,與產品發生互動,理論上這些資料都要收集起來。

當然監控是多方面的,收集哪些資料視情況而定。總之你想了解產品的任何情況,都可以通過設計採集規則然後收集資料來實現,這方面是非常靈活的,並不僅僅限於大家熟知的那幾個指標。

為什麼要選擇自研?

前端監控發展到現在,必然會有成熟的第三方平臺。目前國內最常用的有三個:

  • sentry
  • webfunny
  • fundebug

首先 sentry 和 fundebug 這兩個平臺是付費的,而且你的資料越多費用越高,相當於是資料託管平臺。webfunny 雖然可以私有化部署,但是它的功能是固定的,沒法改程式碼,這就是它的缺點:不夠靈活,無法定製功能。

所以目前雖然市面上已經有成熟的監控系統,但依然有很多團隊選擇自研。一是資料可以儲存在自己的伺服器上,不用另外花錢;二是靈活性強,可以自定義功能,比如你可以在觸發異常時,接入自己的釘釘或企業微信訊息推送,這就需要你的監控系統靈活性很高。

還有我們上面說的,自定義採集規則。我認為這個是最重要的原因。不同規則採集到的資料不一樣,因此第三方標準的採集規則可能並不符合你公司的需求。比如有的公司需要獲取裝置標識作為唯一 ID,有的公司卻需要使用者標識。這是由業務決定的,每個公司都不一樣。

我司前端組就是自研前端監控平臺。優勢就是可以自定義自己的採集規則,設計自己的資料庫儲存欄位,資料都儲存在自己的平臺,靈活性和可靠性都非常高,能滿足自己的多樣性需求。

自研前端監控的技術棧

先上結論,我司的前端監控是前端組自己搞的,所以技術棧是 React + Node.js + MongoDB

這是一個比較常規的技術方案,前端自己搞嘛,所以技術棧都以 JS 為主。同時這也是前端比較能琢磨明白的東西,算是一個標準方案吧。

其中,Node.js 部分我們使用 express 框架寫介面,介面總體分兩大類,就是 寫入查詢統計,作用呢就是前端採集到資料之後,要通過呼叫介面儲存。之後在監控面版上,也要通過介面將資料查詢展現出來。

介面的背後就是 MongoDB 資料庫,作用就是儲存我們採集到的資料。為什麼選擇 MongoDB 呢?最主要的原因就是它的寫入效能非常高,寫入速度非常快。上面我們說,監控系統在採集行為資料的時候,寫入非常頻繁,那麼對寫入效能的要求就非常高,反觀查詢反而要求不那麼高。

這裡也有比較難啃的點,就是採集到大量的資料之後,我們需要各個維度的統計分析。比如:

  • 某個時間段使用者的訪問次數和訪問時長排行
  • 某個時間段頁面的訪問頻率和停留時間排行
  • 某個時間段介面報錯的次數以及佔比統計

這些比較複雜的查詢統計,主要用到 MongoDB 的聚合查詢。前端寫個基本的分組統計還行,這類複雜查詢我們就捉襟見肘了。怎麼辦呢?我們用很長一段時間啃掉了 MongoDB 聚合查詢的所有文件,按照需求一個一個找函式,看哪個能實現,幾乎把所有聚合函式都翻了一遍。

介面做完,最後用 React 實現一個管理後臺,將資料以圖表,表格的形式展示出來,就可以實時看到線上產品的使用情況了。

當然還有一步,就是寫一個對接釘釘或企業微信的通知介面,在觸發異常的時候發起通知,讓我們能及時知道異常情況。我們的通知是這樣:

20220512094939.jpg

這個資訊就能比較全面的看出來是哪裡出了問題,如果看更詳細的錯誤再去異常面板去找:

20220512100007.jpg

總之首先對介面異常全面監控,確認資料沒問題之後我們再前端去排查,效率提高了,鍋也少背了,這不是兩全其美嗎?

最後我們自研的這個小系統在產品上線後發揮了很大的作用,受到了老闆的表揚,這樣讓我們受到了鼓舞,繼續完善它~

更多資源

本文來源公眾號 程式設計師成功。作者楊成功,專注於前端工程與架構的分享,關注我檢視更多硬核知識。

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