感覺已經好久沒有寫博客了，也是一直在開發新的項目，眼看項目逐漸進入尾聲。趁熱整理一下，近期做的有關廣告頁面監控的項目。
看過我前幾篇文章的話，應該了解我一直在開發、維護，我部門廣告的前端展示。但是既然是人寫的的代碼，又怎么會一點錯都不犯呢？盡管有自動化測試、測試人員的功能性測試也難免在實際使用中，數據不匹配造成的瀏覽器端的拋出異常、資源不展示等一系列的頁面廣告異常。那么我們平常是怎么發現並處理這些異常的呢？在沒有監控的時候，往往是投放和業務同事，甚至是客戶發現的。業務同事發現的會發郵件，客戶發現，就會投訴，如果問題比較不好修復或處理的不及時，就會造成退款等一系列嚴重的后果。這樣我們顯得很被動。
如何應對這樣一種被動的處境。首先我們先分析一下，這種處境是怎么造成的？首先廣告異常的出現是無規律的，我們可以優化處理問題的反饋流程。我們看一下原來的反饋流程（如圖1）：
可以看出，在客戶（或業務同事）發現，反饋到解決問題重新上線這段時間是很短很倉促的，我們在修改的過程中很容易造成二次bug。而在上線到客戶（或業務同事）發現問題這段時間有比較充足的時間，我們利用后者的時間段修改bug要比前者要時間充足並且可靠的多。我們可以利用大段的時間來用於修改問題，甚至提前與客戶發現問題，而在客戶發現問題前修復上線，並減少問題在線上停留的時間。所以我想出了下圖的處理問題的機制，新的機制主要在於利用主動監控來縮短問題暴露的時間，加快處理問題的進程。
接下來要做的事情就是開發這樣一套監控報警機制。
客戶端想要記錄報警日志，就必須向后台發送異步請求。整套系統分為前台和后台兩大部分。
我主要負責前台這方面的開發，而在前端的工程中有兩個大的模塊。監控與報警。下面分別針對這兩個方面來分析一下開發時的注意點。
一、監控
說到監控就是發現問題，整理封裝成一定的格式，並發送給報警模塊，交由報警模塊來處理。要監控的方向主要分幾個維度：業務、技術、主動層中間件、被動監聽等。廣告的展示邏輯是由我們寫的我們只要編寫好一個相關模塊，暴露出api在各個監控的代碼邏輯中調用即可。
1、主動層中間件，我們在自己的js代碼中加入中間層的驗證，其實是很方便的，我們自己是很了解這一段js寫的是什么，入口數據應該滿足那些驗證、期望出口得出哪些數據我們應該主動在容易出現問題的關鍵節點，加入我們的驗證判斷。這樣也能跟好的定位問題是來自上游數據還是自身邏輯。要注意的是中間件的處理不能阻礙正常的js邏輯。所以建議將這一層做成異步的。對於監控來說，數據驗證的結果，並不應該影響后續的正常邏輯，也不能作為其依據。
2、被動監聽，這種主要是依賴瀏覽器提供的錯誤事件以及對有危險的js進行try catch。相應的api主要有window.onerror <img>的error事件和 try catch 等。
3、以上的都是技術層面的監控。但是很多的問題其實是來自以於業務需求的，結合需求找到對應的點，進行業務邏輯的驗證，看看是否符合需求。
二、報警
簡單來說報警是對監控所得的數據的提交。我們很容易想象到要通過異步接口的方式來實現。要注意以下幾點：
1、是公司的頁面不一定都在同一個域名下面，所以要做跨域處理。這個不難，jsonp就可以了。
2、有監控層面來的數據五花八門，這是一個提交數據的寫入接口，對於安全性的要求我們自然要注意，安全起見，我們采用參數綁定的方法，將錯誤分為幾類（我的項目中錯誤一共分為10類）約定了不同的替代參數。上面的錯誤類型只是大體上的划分，並不能准確的描述問題，我加入了補充說明的參數，當然補充說明的字段也是和后台約定好的，超出這個范圍的值，都認為是不合法的請求，不會記入數據庫。
3、由於我們的參數有限定，那么重復的請求（除了時間以外的所有參數都一樣）將在一定時間段內不會記入。基本策略參考了debounce的思路，相同請求的最后一次開始一段時間內，不在處理相同的請求。
總結，以上就是我最近開發廣告頁面監控的大體思路，沒有粘出具體的代碼實現怕限制了大家的實現，相信也不難理解。在這條持續集成的路上，很高興可以不斷的將更深層次的需求，結合技術實現的挑戰。