前端監控一般包括三方面：異常監控、性能監控（First Meaningful Paint、First Contentful Paint等性能指标監控）及行為數據監控（PV、UV、頁面停留時長等監控）。其中前端異常監控主要監控因前端代碼執行異常、接口請求異常等導緻頁面出現異常，得不到預期結果的情況。從異常導緻的問題表現方面來看，前端異常監控平台應能夠幫助開發者輕松應對包括但不限于以下問題：

• 業務日益擴張，很多重要但較低頻的報錯事件不會使接口成功率降低和預警，導緻問題不能及時發現。
• 對于有些報障反饋的問題，利用測試賬号構造類似的數據無法複現。
• 接口報錯事件反映前端傳參不對，但當前請求相關的前端代碼沒有邏輯問題，需要花費較多時間推測可重現場景及尋找根源。

當前業界涵蓋前端異常監控的成熟方案有很多，但這些平台也有使用定制困難等不利方面：

• 這些平台幾乎都是收費的，有的跟雲服務打包出售，有的單獨出售。
• 這些前端監控平台的架構都是不開源的，大多數使用者沒有辦法對這類前端監控平台通過二次開發得到适合當前項目的前端監控平台。
• 這些前端監控平台大部分都不支持私有化部署，使用者無法得到監控數據做更深入的分析。
• 這些平台的功能定制化能力比較差，即使個别定制化能力比較好的平台，若想達到期望監控的效果，需要做比較複雜的定制或者較多地侵入業務項目邏輯。

因此我們自研了愛奇藝智能前端監控平台——鷹眼(Hawkeye)，目前該平台已接入了愛奇藝内容創作、分發和變現平台的大部分業務，經過幾個月的使用，幫助業務及時發現了不少問題，也幫助業務負責人對各自系統的整體的運行狀态有了更深入的了解，對線上項目起到了很好的保障作用。

本文将從設計和實踐方面分别對該平台進行詳細闡述。

鷹眼是以幫助及時發現問題、加速業務項目排障為目标的前端異常監控平台。尤其善于應對業務繁多的場景，在對相對低頻而又重要的業務進行監控這一方面表現非常理想。

鷹眼主要有以下三點優勢：

• 提供事件聚合問題列表，支持業務類型隔離監控報警，支持按照異常業務碼配置去監聽接口請求錯誤，能幫助前後端開發人員更容易、更及時的發現系統問題。
• 會記錄發生錯誤事件之前用戶的操作和接口請求，并支持通過前端生成或記錄接口返回的Trace Id來串聯前後端鍊路，為異常排查提供更多的線索。
• 接入簡單快捷，對代碼的侵入性低。

整體架構如圖1-1，包括了采集JSSDK, 後端采集服務，監控後台三部分。

圖1-2 問題管理

二. 業務類型隔離監控報警，支持按照異常業務碼配置去監聽接口請求錯誤

對于接入了10 業務類型的單頁面應用，若隻按照項目劃分，不利于各業務負責人發現各自關注的問題。因此，我們支持建立業務類型、接口返回錯誤碼以及報警Topic Id等的映射配置，之後在問題收集、監控報警、統計分析等各個過程中可根據配置進行定制化處理，如圖1-3示意。

圖1-3 按照業務配置監控

具體說明如下：

• 前端統一攔截Ajax/Fetch接口請求，根據配置傳入的業務錯誤碼去采集接口的報錯信息。這樣的方式對于業務項目邏輯是無侵入的。通過window.addEventListener的方式可以監聽到網絡請求的異常隻能監控到Ajax失敗的請求，但無法判斷HTTP狀态碼，并且有的業務接口返回的HTTP狀态碼CODE是200，業務真正的錯誤碼在Response Body中返回。因此對于Ajax請求監控，采用重寫XMLHTTPRequest的方式采集錯誤。同時為了做到低侵入式的業務隔離監控，我們采用業務錯誤碼配置的方式來監控接口的報錯情況。
• 待辦問題列表按照業務配置區分展示，幫助各個業務負責人及時對當天的項目問題進行整體把握。
• 同一平台項目下，報警按照業務區分，不同業務的報警不會相互影響。

三. 收集錯誤上下文，利用Trace Id串聯前後端鍊路

有些異常事件的發生并不隻涉及一次用戶操作或接口請求，而可能是異常發生之前的接口超時引起的或者某個特定的操作系列導緻的報錯。因此對于當前報錯之前的用戶操作或請求以及請求耗時也需要進行收集，幫助快速定位問題。

圖1-4 錯誤上下文

對于接口請求異常，鷹眼支持記錄後端返回的Trace Id串聯前後端的鍊路監控，這樣能夠在前端監控發現問題時，直接根據Trace Id查看前後端的整個鍊路，關聯業務日志，分析異常環節，快速定位問題。

同時，鷹眼也支持前端生成Trace Id，通過設置HTTP請求頭實現(如圖1-5)，請求頭遵從公司Rover全鍊路追蹤系統的數據規範。

圖1-5 前端生成Trace Id

四. 基于公司大數據平台與流式計算平台建設監控後台

鷹眼異常監控系統構建在公司大數據平台與流式計算平台之上，後台技術架構如圖1-6所示。

圖1-6 監控後台技術架構

數據源：前端上報的異常事件會首先進入消息隊列當中，作為統一的數據源供後續存儲和計算使用；同時，使用消息隊列也是一種削峰的手段，避免業務高峰時期大量上報的異常事件拖垮服務。

引擎：引擎層分為存儲引擎和計算引擎。存儲引擎：根據數據類型與特點，選擇合适的數據存儲。使用Redis生成異常事件的錯誤ID，根據項目、異常類型、異常值等維度生成唯一的錯誤ID，同一類異常事件将聚合在相同錯誤下。使用ES存儲異常事件中的部分字段，主要用于鷹眼監控平台中檢索使用。使用HBbase存儲異常事件的全部字段，因為上報的異常事件中包含了異常堆棧、上下文等信息，數據量較大且并不用于檢索，因此選擇了适合存儲海量數據的HBbase。MySQL主要存儲一些配置信息，例如項目設置、報警配置等。計算引擎：主要使用流式計算引擎Flink對上報的異常事件進行實時的計算和聚合。

目前鷹眼監控已接入了愛奇藝内容創作、分發和變現平台的大部分業務，在日常工作中大幅度輔助提升了運維效率，具體表現如下：

• 通過查看當前的問題列表（如圖1-2）及時發現問題，先于用戶報障發現問題。業務開發同學可以選擇各自業務的問題查看，後端同學可以設置默認展示Service API Error（接口報錯）查看。
• 通過Stack Trace、用戶設備環境信息、Trace Id等快速定位問題, 通過錯誤上下文快速排查疑難雜症，如圖1-4，圖1-5。其中利用Trace Id的全鍊路監控可以顯著提升接口報錯的排查效率。
• 通過各種維度的統計，去分析項目的運行狀況。鷹眼的數據方便接入各種可視化平台統計分析，可分析項目問題發生的趨勢，以及各個項目問題解決的情況。比如利用Grafana出色的多數據源支持和報表功能，進行數據報表的開發和展示，如圖1-7。

圖1-7 統計分析

以上所述，鷹眼已經可以很好的滿足我們日常業務中的監控需求，但還有幾個方向值得我們去思考，例如，在SDK代碼體積，需求程度、開發成本等之間做權衡時，可以考慮是否需要實現以下功能：

頁面崩潰：頁面崩潰後，正常的上報流程就無法走通了，如果需要投遞頁面崩潰前相關信息，可以通過beforeunload結合sessionStorage，在下次打開頁面時上報，如果項目使用PWA(Progress Web Application)，也可以在SserviceWworker實現上報。合并日志：如果用戶訪問量大，上報日志多，或用戶反複觸發同一個錯誤時，我們考慮是否需要将幾次日志合并到一起再上報。HTTP2.0：HTTP2.0上報頭部壓縮，多路複用的優點，會使監控投遞性能更高。

在未來我們将繼續優化擴展鷹眼的能力，比如：盡快提供小程序SDK，提供更多WEB框架的支持，幫助更多技術棧的開發者們及時發現問題、快速排障。同時也會盡快将開源提上日程，以便更多有需要的開發團隊使用和借鑒。