前端異常監控實踐

背景

以前寫了一篇年終總結的文章，有些朋友對咱們在作的監控比較感興趣，特此寫一篇文章來梳理咱們的總體的一套思路給你們參考。

前端異常監控系統的開發其實並不複雜，開源實現方案也頗多，技術實現成本並不難，痛點有可是並非都不能解決，根據咱們的狀況總結了一下：

• 前端SDK，主要是用戶行爲追蹤，錯誤攔截，上報策略，API設計。
• 上報的日誌實現實時查詢。
• 分級分層預警。
• 日誌分析策略。

前端SDK

用戶行爲追蹤

捕獲用戶的操做路徑，根據操做路徑咱們去還原用戶的使用場景，來幫助咱們快速定位問題的所在。

操做路徑分爲如下幾個點：

• 事件觸發。根據業務場景，只截取了用戶的點擊（click/change）和拉動滾動條。
• 瀏覽路徑。這塊分爲2種狀況，spa和多頁面應用，多頁面應用咱們能夠經過 referrer 來確認上一個頁面的url。spa的頁面咱們是對路由進行函數進行監聽來作到。

固然這塊總體的數據咱們會基於cookie和localstorage來存取數據。

異常

腳本經過window.onerror以及攔截angular和vue的handleError來獲取。 ajax這塊除了ajax報錯信息以外，也會根據業務層面的需求攔截返回的錯誤（栗子：咱們請求返回除200外都是錯誤，因此總體都會上報）。

異常這塊其實坑仍是蠻多的，不過市面上各位大大總結的夠好了，你們能夠看看各位大大的總結。

操做系統

這塊就是整個系統的信息，以及瀏覽器的信息、ua等。

總結

sdk這塊其實2個難點，一個是用戶行爲如何定義？另外一個異常收集這塊會有蠻多的坑要踩。 另外一部分總體的上報策略，目前咱們是對異常進行了分級，低級別的錯誤延遲而且合併上報，同一個點同一種錯誤去重上報。

日誌收集

全部日誌都打到nginx，而且nginx備份日誌，請求代理到後面的node服務，node服務清洗數據後進行入庫，這塊有一個要注意的點，若是node服務被打死，整個數據就斷掉了，因此這塊咱們有一個定時任務從nginx備份的日誌裏清洗出因爲服務掛掉沒有處理的請求。

爲何沒有用到你們都比較愛使用的elk呢？ 答：經過調研目前咱們的量級其實尚未徹底要上升到須要elk的層面，咱們更傾向於一種可控的狀態。

預警

預警服務採用分級策略，按照組織架構，高級別的異常上來後，一段時間沒有處理，預警系統會觸發向上彙總的策略，直到部門負責人。

展現分析

目前這塊會相對薄弱一些，基本只分析了一個週期的項目狀況。整個重心仍是在錯誤的解決層面。

總結

前端sdk更偏重於前端的異常收集。總體的後端服務，實際上是面向於全部的異常來作的，咱們更傾向於給公司提供一套完善的日誌系統（ps：目前咱們團隊的後端監控的數據也逐漸的上到該系統）。

最後但願感興趣的同窗加入咱們團隊email:liuqing@liluo.me（除前端外，咱們也招python，爬蟲，大數據）, 也但願各位能給咱們提些意見和建議，畢竟組內的同窗們也是經過業餘時間來把總體的方案完善，而且開發完成，還有不少須要提高的地方。