前端 線上監控篇
「
關於前端項目的線上監控，網上其實已經有很多現成的文章。所以關於那些大家已經比較了解或者已經被講解過很多次的技術點，本文就不再重複說明。例如：異常跨域捕獲問題、setTimeout/promise等的try()catch(e){}問題等。
當然，網上此方面的文章，主要還是關於前端異常捕獲的分析。
而本文分享的重點是，整個監控體系的搭建和使用，涉及到前端、後端服務、資料庫等方方面面，以及一些應用場景的舉例。
沒錯，當前的前端技術棧已經足夠支撐我們來完成這樣一個平台性項目的開發，感興趣的朋友，不妨試試。
」
1
背景
線上有挺多不錯的雲監控平台，為什麼要自研？
一般公司，可能都有一個牛逼的數據平台，為什麼要自研？
關於這個問題，其實就要就具體情況來分析了。
例如平台的功能定位問題，有可能現有平台主要面向運營和產品，偏重數據埋點和用戶數據分析，那麼其技術屬性偏弱，不能滿足你的需求。
再例如現有平台基於穩定和通用性等因素，可能針對你的需求要麼需要經過較長的排期，要麼你的需求太定製化了，置之不理。
總的來說，不同的公司，其實情況不一樣，不可一概而論。但是有一個基本點要強調一下，我們要自研的這個監控平台，主要是基於技術和定製化需求，不是用於替代常規的埋點和大數據平台的。所以接下來講述的時候，大家也可以基於這個點來理解平台的一些功能等。
2
管理後台設計
管理後台，是負責數據最終結果的可視化展示和配置的。所以無論代碼流程是怎麼樣子的，管理後台是一切成果的終極體現，其好不好用，清不清晰，直接決定了這整個產品的用戶體驗。所以，這裡優先講一下管理後台的設計和一些功能點。
首頁
如上圖，左側是菜單，右側是首頁的相關說明，一個很常規的布局方式。
重點講一下，建議數據模塊以項目為單位進行劃分（圖中黃色框框部分）。筆者看過一些平台是使用域名進行劃分的，這種方式，如果多個項目使用同一個域名的話，那麼數據都混在一起了，多有不便。
項目數據匯總
如上圖,右側為數據匯總展示區域。
「載入時間」圖表: 用於展示首屏渲染、網路請求耗時等數據
「頁面訪問情況」圖表: 展示頁面pv
「js heap」圖表: 內存使用情況
「資源情況」圖表: 資源（圖片、css、js、iframe等）耗時佔比；如果你的頁面中未使用iframe，而此處卻發現了iframe，那說明你的頁面很有可能被第三方注入代碼了
如上圖,右側為數據匯總展示區域。
如上圖,右側為數據匯總展示區域。
「頁面慢載入」表格: 用於展示載入較慢的記錄。
「全部域名」表格: 用於展示全部域名的資源耗時佔比情況；上面的「域名情況」圖表只能展示一小部分的域名情況，如果是http網站，被劫持的可能性非常高，那麼域名的數量會非常多。
實時自定義數據獲取
如上圖，通過aggregate查詢，可以實時獲取自定義的數據（這些數據，是通過介面上報上來的定製化數據）。這個功能模塊，我們主要用於線上不可重現問題的定位或者一些爭議數據的校驗，舉個例子：
關於線上的不可重現問題，很多時候我們只能靠猜。而有了這個功能後，我們就可以採用類似在本地使用console.log列印日誌定位本地問題的方式來定位線上問題了。
功能並不複雜，但是這提供了一個獲取線上信息的方式。那麼，基於此，其實還是有很多其他的應用場景，在此就不一一列舉了。
郵件通知
工作比較忙的時候，常常會忘記或者沒時間去一一查看項目中的各種數據。
所以，這裡還提供了一個每日郵件匯總功能，將前一天所有項目的關鍵數據（例如：達到一定數量級別的錯誤、慢載入等）發郵件給各項目的前端負責人，如下圖：
關於圖中藍色框框部分，其實不是前端異常，而是調用客戶端介面報的錯，那麼關於這部分錯誤，還會提取出來，發郵件給各項目的客戶端負責人。
3
架構
前端捕獲
接受監控的網頁，需要引入一個監控js（由管理後台根據項目配置，動態生成），那麼這個js的作用主要是：捕獲並上報js異常和頁面timing、memory、resources等信息，當然也提供了方法，用於上報定製化數據。
關於js異常捕獲的問題，這裡就不做詳述了，有興趣的，可以去網上看看相關資料（BadJS之類的）。
頁面載入性能和資源信息，可以通過window.Performance獲取到。當然這個對象也存在兼容問題，我們的處理方式是不兼容的不上報，做好容錯處理，不影響正常業務代碼執行便可。大部分的現代瀏覽器都是支持的，所以對我們的監控影響也不大。
關於window.Performance的處理，類似下圖。至於圖中的代碼和列印出來的欄位的意思，可以到網上和github上面查看。
後端服務
如上圖，採用了nginx進行各協議請求的轉發和負載均衡等，後端web框架使用的是hapi。這裡應該有人有疑惑了，為什麼不是koa，不是express等，這些在國內都比較火呢。大致原因如下：
這個庫本身也是足夠優秀的，大團隊、高性能、高穩定等等，這個可以查看github和網上相關資料
用起來方便、舒服
和本項目也挺搭的，服務搭建快捷
總的來說，優秀的框架或庫總有那麼幾個，選一個適合自己的，適合項目的便可。
後端服務大致結構如下圖：
其中的sinopia公共模塊，主要是提取了三個後端服務模塊的公共的資料庫操作庫以及工具庫，放置於內部倉庫中，好處不言而喻。 而其他部分，將在下文一一講解。
資料庫
我們使用的是mongodb，主要基於以下幾個方面考量：
高伸縮性
日誌高IO
nodejs高匹配
不是很複雜的資料庫操作
工具庫主要是mongoose，這個就不多說什麼了，nodejs+mongodb，再加上mongoose的話，是不是很搭...畢竟這也是主流嗎，哈哈哈。 關於資料庫的具體操作，會在下文提及。
server
該模塊用於為前端的監控js提供介面服務，主要就是數據信息記錄的作用。
其功能不會很複雜，保障高可用是最重要的指標，因為它是唯一向外提供介面的模塊，並發量也會比較大。所以，除了常規的運維側優化，保持介面邏輯的精簡也是重要的手段。
大致的原則是，介面盡量簡單化，然後把複雜的邏輯都轉移到數據處理模塊schedule。舉個列子：
一個頁面的載入，會涉及到各種資源，css、js、圖片等。那麼每次打開頁面後，需要把和本頁面並且是本次打開的相關資源的相關數據一次性（分批次的話，請求量暴漲，自行考量）上報到伺服器，那麼其數據結構便是一個對象列表，而對應到資料庫端，便是嵌套文檔的結構。沒錯，沒毛病，一切都很自然。 但是，這樣開發出來的介面，在性能方面並不理想。
解決之道，就是把對象列表作為json字元串存進資料庫（即其對應的mongoose欄位數據類型為String），然後在數據處理環節做JSON.parse。如此改造之後，具體數據我忘了，性能大概提升了20%～30%。
然後，由於其對外提供服務，安全性也是需要著重考慮的，安全測試、數據請求大小限制（使用get等）、數據格式檢查、模塊關鍵字校驗等，這些都是需要做的。
schedule
數據處理模塊，主要是用於對前一天上報的數據進行分析和處理。
設想一下，一個pv為500萬的頁面，其產生的數據記錄一般都是其訪問量的好幾倍（資源數據、載入性能數據、異常數據等），然後一個項目可能有好幾個頁面。這樣一天下來，就可以產生上億條數據記錄。 而，這僅僅是一個普通項目一天的數據量。這麼大的數據量，如果不作處理，一個是查詢的時候，處理緩慢，第二個，遲早把資料庫擠爆。
如上圖，這是基本的處理流程，舉的是timing的例子，但是其他類型的處理流程也是大同小異。
大致是，運行定時任務，於第二天凌晨，把前一天的原始數據取出來，處理完成後，歸入對應的結果數據文檔，然後把前兩天的數據清除，就是說只保留處理完的數據。 基本流程也不是很複雜，但是這部分數據量比較大，容易出現內存溢出，資料庫鏈接異常等問題，需要小心處理。
同時，還需要考慮另外一個問題，像其他的模塊，程序異常，只要自動正常重啟就行了，但是這個模塊，如果數據處理到一半，出現異常了，怎麼辦，卻是一個比較麻煩的事情。因為重啟後，剛剛執行到一半的任務還做不做，從哪裡開始，這也是一個比其他模塊複雜的點。
首先，這裡說的是數據正常，但是程序掛了的問題，關於數據異常導致的問題，下文會提及。
目前的做法是，把每個項目的數據處理流程當作一個事務（不是資料庫事務，而是用代碼邏輯保證的），每完成一個項目的數據處理便在伺服器本地文件中記錄下來。萬一程序掛了，自動重啟後，首先讀取該記錄文件，然後已記錄的完成的項目，不做處理，未記錄的項目，需要做以下幾件事情：
從相關的處理結果文檔中，查找是否存在未記錄項目的前一天的數據，有則刪除
重新對未記錄項目進行數據處理
其中第一項，是為了把執行了一半的項目的數據清除，避免數據重複。第二項，就是把未處理的項目，處理完成。
manage
管理後台就比較簡單了，主要是堆代碼，前端是使用vue全家桶（寫的比較早，so，版本不是很新）現實的，後端還是hapi，然後使用hapi自帶的state management做好簡單的登錄和訪問授權即可。
高可用
首先，運維是基礎，做好常規的伺服器和資料庫集群等是高可用的重要保障。
然後，pm2是一個帶有負載均衡功能的node應用的進程管理器，下圖是server模塊的pm2配置文件，可參考一下：
關於上圖中每個配置項的意義，就不做詳細說明了。其中涉及到日誌記錄、運行模式、進程個數、日誌格式等，如有疑問的，可以到網上查查。
接下來，儘可能詳細、有序的日誌記錄，這個對於你後續發現和定位問題都是及其有幫助的。原則上來說，就是在性能和儘可能詳細之間折中吧。
還有關於上文提及的異常數據，採用的處理方式是：
跳過不處理
對於這種情況，除了記錄報錯信息，還會把數據信息記錄到日誌
把異常數據記錄下來，是為了方便查看和定位問題，但是為了避免日誌體積過大（萬一異常數據很多或頻繁），第二項中的數據信息的記錄，對於雷同的數據，只記錄一次，不會重複記錄。
最後，就是各種細節問題了，做好壓力測試，不間斷的調優等等，還有就是上文已經提及的，各業務模塊定製化的優化處理。
4
總結
說了這麼多，不知道大家有什麼感覺，筆者覺得這樣一個平台，好處多多，大家是可以擠點時間嘗試一下的（畢竟筆者也是利用空餘時間進行開發的，做人要有自信，哈哈哈...）：
不要怕出錯，畢竟即使出錯了，也不會影響正常的線上業務
可以讓你對於線上項目的健康情況，有一個比較清晰的了解
幫助你定位和解決一些，以前讓你無計可施的，開發和測試環境都無法復現的問題
輔助提供線上項目的可量化數據指標
此處省略一萬個優點...
就講這麼多吧，很多細節這裡沒辦法涉及到，感謝各位捧場！
「魅族開放平台」每周推出一篇魅族工程師的分享，如果覺得文章不錯，就請分享給身邊的朋友們吧~
TAG:魅族開放平台 |