背景
之前寫了一篇年終總結的文章，有些朋友對我們在做的監控比較感興趣，特此寫一篇文章來梳理我們的整體的一套思路給大家參考。
前端異常監控系統的開發其實並不複雜，開源實現方案也頗多，技術實現成本並不難，痛點有但是並不是都不能解決，根據我們的情況總結了一下：
- 前端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，爬蟲，大資料）, 也希望各位能給我們提些意見和建議，畢竟組內的同學們也是通過業餘時間來把整體的方案完善，並且開發完成，還有很多需要提升的地方。