線上監控作爲產品質量的最後一道屏障，其意義和影響都十分重大。阿里嶽鷹團隊從內部業務痛點出發，沉澱了一套 Web 前端全景監控方案。在監控方面，實現了常規的 JS 異常、資源加載異常、頁面性能以及接口請求監控，並且支持自定義上報，以滿足全鏈路中更多的場景。同時，團隊聯合 UC 瀏覽器內核團隊，獨創了基於 V8 的“頁面白屏”監控。在問題分析和解決方面，打造了一套高效的問題分析和智能預警體系。本文整理自阿里巴巴前端技術專家陳周勉在 GMTC 2019 深圳站的演講，本次演講結合大量實踐案例分享了平臺一路走來的歷程，希望能對大家有所啓發。
大前端時代
前端開發的痛點
我們正身處於一個大前端時代。以目前來說，我們的技術還是比較主流的，在 PC 端或移動端，還有很多新的 IoT 客戶端上都有着廣泛的應用。同時，我們的新技術、新框架的發展也十分迅猛。引用賀老的話來講就是：“前端，在這個階段，感覺是有點學不動了。”那麼，這個時候會面臨哪些挑戰呢？主要有以下三點：
- 兼容性
- 終端
- 用戶體驗
除此之外，再加上前面的“學不動”，就導致了前端開發羣體的現狀——我太“南”了。那麼，針對於這些問題，我們有沒有改善甚至完全解決的辦法呢？答案顯然是有。
事實上，我們可能只是需要一個 Web 監控分析平臺，以達到線上監控的目的。一方面，線上監控可以對應用的健康狀況做實時的監控和預警；另一方面，在預警出來後可以合理、及時地分析和解決問題。而嶽鷹做的就是這件事情。
在硝煙中誕生
回顧這個大前端時代，業界方面，在整個監控領域內已經催生了很多監控產品。不過這些產品大都趨於同質化，他們可能更多還是基於應用這一層的 SDK 去實現，一旦在某些方面（例如白屏之類的問題）有更深層次的要求，就沒有辦法很好地滿足了。
阿里的前端業務量級是衆所周知的，體量非常龐大。由此催生出了對於前端監控的訴求，尤其是白屏問題，因爲阿里的用戶基數特別大，一旦出現白屏現象，對於整個用戶體驗的傷害極大。
UC 在互聯網算是老兵了，而且是排頭兵，UC 長年深耕於瀏覽器領域，所以 UC 的內核團隊在底層方面已經有了比較深厚的積澱。比如說 H5、Web 容器這些方面都有着比較深厚的功底，這些再加上部分業務場景的觸發和 UC 自身的優勢，就構成了 UC 做監控平臺的思路。緊接着，嶽鷹就在 UC 內部開始孵化，逐漸在自己的業務裏錘鍊、沉澱，最後發展到可以爲外部用戶提供服務。
嶽鷹平臺的探索之路
傳統的監控解決方案
傳統的解決方案，大致會有這幾步：
首先是前端的上報，我們通常是通過 JS SDK 進行數據的採集和上報，在經過後端的鏈路時，我們會做一些聚合分析然後展示到我們的 Web 監控平臺；平臺直接面向開發者，爲開發者提供一系列聚合分析的手段；最後給我們的開發者賦能，讓他們可以更容易地發現線上的問題，同時也輔助他們高效地分析問題。
那麼，這樣的方案是不是足夠完美呢？未必。
傳統解決方案的弊端
傳統的解決方案存在一些弊端：
- 監控維度有限
- 問題分析能力弱
- 需要前端埋點
首先是監控維度上受限，因爲 JS SDK 在偏上層，所以它在實現功能的時候會有比較大的侷限性；其次是我們在遇到問題的時候，如果沒有足夠的信息輔助分析，就會束手束腳，JS SDK 在此是沒有辦法獲取更多有用的信息來輔助我們進行問題分析的；最後一點就是這種解決方案需要提前進行手動埋點，雖然不是致命的弊端，但是對於一些體量大的業務來說就意味着高成本和低效率。
我們的思考
針對於傳統解決方案的不足，我們進行了思考。傳統解決方案有一個天然的優勢，那就是 JS SDK，因爲它是跨端的，這一點很多方案都無法彌補。所以我們留下了 JS SDK 作爲基礎的跨端方案。其實我們完全可以通過另外一個方式，再結合 JS SDK 這個方案來構成整體的監控方案。
通過什麼方式呢？答案是瀏覽器的內核。打造一個可以做深度能力補充的監控 SDK，再結合我們的 JS SDK 的跨端能力，就可以實現整個場景的覆蓋。
內核 SDK 的原理和優勢
內核是如何工作的呢？
傳統方案的 JS SDK 是工作於頂部的 Web 頁面這一層，但其實無論是 Web 還是 App，JS 最終都是在 JS 引擎裏面執行。如果沒有這一層的話，當 JS 有異常透出的時候，它會通過一層過濾之後到 SDK，最終到運營平臺。爲什麼要加上中間這一層呢？因爲中間的這個過濾器，如果有用過監控平臺的同學可能會發現，有時候拿到了一個堆棧的棧頂信息是 Script Error，因爲它跨域了，所以最終 V8 出來的異常是比較抽象的，對於我們定位問題沒有什麼幫助。而內核工作在底層，通過一個鏈路進行上報，彌補了 JS SDK 的不足，這也是我們最終採用這個方案的一個原因。
無論 JS 異常，還是資源加載，或者是一些接口、頁面性能都是依靠瀏覽器給我們透出來的全局 API 去做的。比如我們需要做 API 監控的時候，需要一個這樣的接口，做頁面性能分析的時候，需要通過接口拿到數據然後才能進行一些聚合的分析。但更細緻的信息我們是得不到的，因爲通過這種方案我們得到的信息是經過過濾之後的信息。
由此就能看出內核 SDK 的優勢，首先它會有更全面的堆棧信息，也會有更細緻的錯誤碼，我們在排查問題的時候更加方便。同時，JS SDK 沒有跨域的限制。除此之外，還有兩個更核心的點，就是首屏性能和白屏監控。
首先，我們整個統計出來的首屏是比較貼近於用戶感官的體驗，在實驗室裏準確率達到了 85%，遠高於以往的分析方式；其次，我們在白屏監控方面也做了創新，以往的 JS SDK 方式進行白屏監控，更多是通過前端頁面的動節點這種相對低效且耗性能的方式，而使用內核則會規避這樣的問題。在問題的信息以及輔助定位方面，內核也更強一些。就拿首屏性能來說，以往我們在 JS SDK 裏面分析性能的時候，如果得到的信息是首屏加載比較慢，那麼當你想要了解原因的時候是無跡可尋的，而內核會收集或定義更多時間段的信息，從而瞭解頁面的問題。
白屏採集原理
什麼是白屏？白屏就是用戶在界面上看到一片空白，追加一種場景就是頁面加載時有一些小動畫，但是長時間仍然沒有內容出來，這種情況就是白屏。我們對白屏的定義就是：頁面加載完成三秒內，沒有任何彙集指令，我們就會把它視爲白屏的現象。那我們是如何對白屏進行採集或者處理的呢？整個頁面是一個渲染的過程，上文提到我們會分析彙集指令來判斷是否白屏，在指令彙集之前，我們畫一個分佈式，來判斷是否有彙集指令，從而判斷是否爲白屏。
常見的白屏原因有哪些呢？通過我們目前所沉澱的數據，大概歸結爲四類：
- JS 邏輯異常
- 核心資源加載失敗
- 客戶端或內核的問題
- 性能
前兩類可能跟業務有關，比如說自己 JS 邏輯存在異常，或者核心資源加載失敗，都會導致白屏現象的出現。而客戶端的問題也就是性能問題，頁面長時間沒有出現內容，這樣的情況也是需要優化的。
上圖的案例是釘釘平臺的某一個業務，這張圖是嶽鷹監控平臺上的一個大盤，在某個時間節點數據會突然出現暴漲的情況，這種情況下白屏率就比較高了。這時，我們的平臺進行了預警，那對於釘釘來說，該如何解決呢？當時，通過嶽鷹提供的一些工具，發現了問題所在：
上圖爲釘釘頁面的主文檔，可以看到它加載 SaaS 時出現了 size 異常的問題，主文檔出現異常，頁面肯定是無法加載的。然後，我們進一步去分析原因的時候發現內容已經被劫持了，但是返回的是 0，這就有可能是端內或是容器上出現了問題，從而導致最終出現了白屏，被嶽鷹捕獲到，這是一個比較典型且相對簡單的案例。
自定義上報 - 滿足多樣的上報訴求
我們的監控平臺在有了 JS 異常、資源加載、API、首屏性能和白屏這些全方位的監控之後是不是就足夠了呢？答案也是未必。在不同的業務中，除了這些基礎的監控之外，還會有更大、更復雜的或者更不一樣的監控訴求，例如均值、成功率 / 失敗率等等，這些訴求就可以通過我們的自定義方式去實現。同時，這樣也可以把我們整個 Web 監控平臺的功能最大化。最後，可以通過擴展來實現我們任意的一個自定義。
- 節流
那麼在上報方面我們會關注哪些關鍵的點呢？在移動互聯網時代，我們還是比較注意流量方面的問題，所以第一個問題肯定是節流的問題，有同學可能會說 ，上一個 HDB2，有一個多路的複用會節省流量。但除此之外，在業務方面也就是 SDK，我們會做一些努力，比如異常的去重、請求的合併等等，目的是爲了讓我們整個請求的數降下來，以達到節流的目的。
- 支持降級
另一個問題就是上報的方式，以往我們大多會採用比較傳統的方式，用 Image 或者一些其他的方式上報，而缺點也比較明顯。所以我們採用如上圖的方式，兩者結合可以做一個降級。
- （動態）採樣
在上報的時候，如果是體量較大的業務，對於嶽鷹的衝擊還是比較大的，如果我們沒有有效的手段就會導致整個監控平臺垮塌，所以我們提出了動態採樣，通過在雲端下發的配置，採集到每一個跟它相關的端，最終達到動態採樣的目的。
- 安全
在安全方面，HBS 這裏也不必贅述，是一定要保障的。
Web 平臺打造
再來看 Web 平臺的打造，這是和開發者息息相關的。我們看一個平臺的核心能力主要是看四個方面：
- 實時監控
- 實時預警
- 多維分析
- 領域工具
其中，實時監控與實時預警這兩點是最核心的，這兩點做的好，我們就不用擔心因爲錯過了線上的某些問題而導致風險的發生。當我們拿到監控數據之後，對數據進行分析的時候不能一蹴而就，這個時候我們需要有多維的分析手段去提供給開發者做決策。而在分析的過程中，我們需要涉及到 JS 異常、性能等各個領域，在分析的時候也會遇到不同的訴求。所以，我們通過各領域內的工具進行打造，以提升我們整體的對於問題的定位以及分析問題的能力。
上圖爲嶽鷹監控平臺的實時大盤，從圖中可以看到很多監控的指標，比如頁面性能、異常、API、流量等，我們通過大盤就可以對應用的健康情況有一個大致的瞭解。同時，在報警方面，我們更多會關注報警規則的支撐，還有其自身的實時性、正確性。
嶽鷹監控平臺有很多的項目，其中性能大盤是其中比較主要的項目之一。我們每一個監控項的閉環裏也需要給開發者提供更細緻的信息。如上圖，圖中的數據會告訴我們應用的整體性能情況，因爲如果單獨去看某一個小時、某一天的性能情況可能意義不大，這時就需要進行對比，用監控的數據與數據來源做對比，才能知道整個的趨勢是怎樣的。
最後是代碼追蹤，在發生異常後，我們需要知道具體是業務上的哪段代碼出現了問題，這也是比較重要的一個分析維度。而上文提到的代碼分析，通常是沒辦法直接看出問題在哪些堆棧上。這時候，如果我們有 Native 文件，就可以通過一定的映射方式，直接把業務代碼還原出來，並找到具體是哪一段代碼出現了問題，找到代碼後，我們可以直面開發者並給他修復建議。
接入場景
對於上文提到的前端埋點的弊端，通常情況下監控的多爲應用級，接入單個應用或單個頁面，我們每新建一個頁面、新建一個應用，就可以讓開發者直接複用我們的監控代碼，把這段代碼植入後就可以進行監控了。在很多場景下還可以對效率加以提升，例如容器級的接入，例如在 UC 的內核上面做全方位的自動監控，還有餓了麼 APP，因爲沒有接內核，直接用 Webview 注入我們的 JS SDK，以達到自動監控的目的。所以，通過這樣的深度支持，我們在效率方面有了比較大的提升。
除了這兩個例子，在內部我們還有支付寶這樣大體量的業務，支付寶用的就是我們的內核，目前直接做到了對小程序的自動監控，開發者不必手動添加多餘的代碼就可以達到自動監控的效果。還有與釘釘平臺的深度合作，釘釘採用了我們 JS SDK 加內核的方案來服務整個開發平臺的監控方案。而且，嶽鷹在經歷了雙十一、雙十二這些大流量的活動後，也凸顯出了服務大體量用戶的能力。
嶽鷹平臺的未來展望
目前爲止，嶽鷹已經能做到實時預警，但未來我們希望可以做到更加智能的預警方式。比如說，有時預警出現一些高峯，當採樣數據不足的時候，是否可以忽略掉，不做噪音的干擾之類的更加智能化的預警。
另一方面，目前前端的技術和框架層出不窮，對於監控平臺來說，我們的願景是能夠真切地幫助到開發者，所以，在未來我們還是會對新型的語言框架做進一步的支持，真正的爲開發者帶來便利。
總結
上圖爲嶽鷹平臺的產品架構，目前運營平臺大概分爲這麼幾個部分，還有一些簡單的輔助性功能，最核心的還是監控預警和問題分析方面的能力。我們在每一個場景都提供了比較好的閉環。最後總結一下：
- Web 監控平臺閉環：採集 - 上報 - 解析 - 計算 - 多維分析 - 實時預警
- 白屏監控原理：頁面加載完成 3s 內無繪製指令
- 領域工具的打造，可極大提升體驗及問題分析解決的效率
嘉賓介紹
陳周勉，阿里巴巴前端技術專家，目前就職於阿里 UC 事業部，擔任研發效能組的前端負責人。近年來主要專注於雲機以及前端監控領域，已對外推出兩款產品——巖鼠雲設備平臺和嶽鷹全景監控平臺。曾主導部門的前端體系建設，精通 Vue 和 React，在前端架構、工程化、性能等方面有較豐富的經驗。