Categories
程式開發

前端的守望者:阿里岳鷹 Web 全景監控平台的建設之路


線上監控作為產品質量的最後一道屏障,其意義和影響都十分重大。阿里岳鷹團隊從內部業務痛點出發,沉澱了一套 Web 前端全景監控​​方案。在監控方面,實現了常規的 JS 異常、資源加載異常、頁面性能以及接口請求監控,並且支持自定義上報,以滿足全鏈路中更多的場景。同時,團隊聯合 UC 瀏覽器內核團隊,獨創了基於 V8 的“頁面白屏”監控。在問題分析和解決方面,打造了一套高效的問題分析和智能預警體系。本文整理自阿里巴巴前端技術專家陳周勉在 GMTC 2019 深圳站的演講,本次演講結合大量實踐案例分享了平台一路走來的歷程,希望能對大家有所啟發。

大前端時代

前端開發的痛點

我們正身處於一個大前端時代。以目前來說,我們的技術還是比較主流的,在 PC 端或移動端,還有很多新的 IoT 客戶端上都有著廣泛的應用。同時,我們的新技術、新框架的發展也十分迅猛。引用賀老的話來講就是:“前端,在這個階段,感覺是有點學不動了。”那麼,這個時候會面臨哪些挑戰呢?主要有以下三點:

  • 兼容性
  • 終端
  • 用戶體驗

除此之外,再加上前面的“學不動”,就導致了前端開發群體的現狀——我太“南”了。那麼,針對於這些問題,我們有沒有改善甚至完全解決的辦法呢?答案顯然是有。

事實上,我們可能只是需要一個 Web 監控分析平台,以達到線上監控的目的。一方面,線上監控可以對應用的健康狀況做實時的監控和預警;另一方面,在預警出來後可以合理、及時地分析和解決問題。而岳鷹做的就是這件事情。

在硝煙中誕生

回顧這個大前端時代,業界方面,在整個監控領域內已經催生了很多監控產品。不過這些產品大都趨於同質化,他們可能更多還是基於應用這一層的SDK 去實現,一旦在某些方面(例如白屏之類的問題)有更深層次的要求,就沒有辦法很好地滿足了。

阿里的前端業務量級是眾所周知的,體量非常龐大。由此催生出了對於前端監控的訴求,尤其是白屏問題,因為阿里的用戶基數特別大,一旦出現白屏現象,對於整個用戶體驗的傷害極大。

UC 在互聯網算是老兵了,而且是排頭兵,UC 長年深耕於瀏覽器領域,所以 UC 的內核團隊在底層方面已經有了比較深厚的積澱。比如說 H5、Web 容器這些方面都有著比較深厚的功底,這些再加上部分業務場景的觸發和 UC 自身的優勢,就構成了 UC 做監控平台的思路。緊接著,岳鷹就在 UC 內部開始孵化,逐漸在自己的業務裡錘煉、沉澱,最後發展到可以為外部用戶提供服務。

岳鷹平台的探索之路

傳統的監控解決方案

傳統的解決方案,大致會有這幾步:

前端的守望者:阿里岳鷹 Web 全景監控平台的建設之路 1

首先是前端的上報,我們通常是通過JS SDK 進行數據的採集和上報,在經過後端的鏈路時,我們會做一些聚合分析然後展示到我們的Web 監控平台;平台直接面向開發者,為開發者提供一系列聚合分析的手段;最後給我們的開發者賦能,讓他們可以更容易地發現線上的問題,同時也輔助他們高效地分析問題。

那麼,這樣的方案是不是足夠完美呢?未必。

傳統解決方案的弊端

傳統的解決方案存在一些弊端:

  • 監控維度有限
  • 問題分析能力弱
  • 需要前端埋點

首先是監控維度上受限,因為JS SDK 在偏上層,所以它在實現功能的時候會有比較大的局限性;其次是我們在遇到問題的時候,如果沒有足夠的信息輔助分析,就會束手束腳,JS SDK 在此是沒有辦法獲取更多有用的信息來輔助我們進行問題分析的;最後一點就是這種解決方案需要提前進行手動埋點,雖然不是致命的弊端,但是對於一些體量大的業務來說就意味著高成本和低效率。

我們的思考

針對於傳統解決方案的不足,我們進行了思考。傳統解決方案有一個天然的優勢,那就是 JS SDK,因為它是跨端的,這一點很多方案都無法彌補。所以我們留下了 JS SDK 作為基礎的跨端方案。其實我們完全可以通過另外一個方式,再結合 JS SDK 這個方案來構成整體的監控方案。

通過什麼方式呢?答案是瀏覽器的內核。打造一個可以做深度能力補充的監控 SDK,再結合我們的 JS SDK 的跨端能力,就可以實現整個場景的覆蓋。

內核 SDK 的原理和優勢

內核是如何工作的呢?

前端的守望者:阿里岳鷹 Web 全景監控平台的建設之路 2

傳統方案的 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 裡面分析性能的時候,如果得到的信息是首屏加載比較慢,那麼當你想要了解原因的時候是無跡可尋的,而內核會收集或定義更多時間段的信息,從而了解頁面的問題。

前端的守望者:阿里岳鷹 Web 全景監控平台的建設之路 3

黃色部分就是內核所帶來的提升

白屏採集原理

什麼是白屏?白屏就是用戶在界面上看到一片空白,追加一種場景就是頁面加載時有一些小動畫,但是長時間仍然沒有內容出來,這種情況就是白屏。我們對白屏的定義就是:頁面加載完成三秒內,沒有任何匯集指令,我們就會把它視為白屏的現象。那我們是如何對白屏進行採集或者處理的呢?整個頁面是一個渲染的過程,上文提到我們會分析匯集指令來判斷是否白屏,在指令匯集之前,我們畫一個分佈式,來判斷是否有匯集指令,從而判斷是否為白屏。

前端的守望者:阿里岳鷹 Web 全景監控平台的建設之路 4

常見的白屏原因有哪些呢?通過我們目前所沉澱的數據,大概歸結為四類:

  • JS 邏輯異常
  • 核心資源加載失敗
  • 客戶端或內核的問題
  • 性能

前兩類可能跟業務有關,比如說自己 JS 邏輯存在異常,或者核心資源加載失敗,都會導致白屏現象的出現。而客戶端的問題也就是性能問題,頁面長時間沒有出現內容,這樣的情況也是需要優化的。

前端的守望者:阿里岳鷹 Web 全景監控平台的建設之路 5

一次真實的案例

上圖的案例是釘釘平台的某一個業務,這張圖是岳鷹監控平台上的一個大盤,在某個時間節點數據會突然出現暴漲的情況,這種情況下白屏率就比較高了。這時,我們的平台進行了預警,那對於釘釘來說,該如何解決呢?當時,通過岳鷹提供的一些工具,發現了問題所在:

前端的守望者:阿里岳鷹 Web 全景監控平台的建設之路 6

上圖為釘釘頁面的主文檔,可以看到它加載 SaaS 時出現了 size 異常的問題,主文檔出現異常,頁面肯定是無法加載的。然後,我們進一步去分析原因的時候發現內容已經被劫持了,但是返回的是0,這就有可能是端內或是容器上出現了問題,從而導致最終出現了白屏,被岳鷹捕獲到,這是一個比較典型且相對簡單的案例。

自定義上報 – 滿足多樣的上報訴求

我們的監控平台在有了 JS 異常、資源加載、API、首屏性能和白屏這些全方位的監控之後是不是就足夠了呢?答案也是未必。在不同的業務中,除了這些基礎的監控之外,還會有更大、更複雜的或者更不一樣的監控訴求,例如均值、成功率/ 失敗率等等,這些訴求就可以通過我們的自定義方式去實現。同時,這樣也可以把我們整個 Web 監控平台的功能最大化。最後,可以通過擴展來實現我們任意的一個自定義。

前端的守望者:阿里岳鷹 Web 全景監控平台的建設之路 7

  • 節流

那麼在上報方面我們會關注哪些關鍵的點呢?在移動互聯網時代,我們還是比較注意流量方面的問題,所以第一個問題肯定是節流的問題,有同學可能會說 ,上一個 HDB2,有一個多路的複用會節省流量。但除此之外,在業務方面也就是 SDK,我們會做一些努力,比如異常的去重、請求的合併等等,目的是為了讓我們整個請求的數降下來,以達到節流的目的。

  • 支持降級

另一個問題就是上報的方式,以往我們大多會採用比較傳統的方式,用 Image 或者一些其他的方式上報,而缺點也比較明顯。所以我們採用如上圖的方式,兩者結合可以做一個降級。

  • (動態)採樣

在上報的時候,如果是體量較大的業務,對於岳鷹的衝擊還是比較大的,如果我們沒有有效的手段就會導致整個監控平台垮塌,所以我們提出了動態採樣,通過在雲端下發的配置,採集到每一個跟它相關的端,最終達到動態採樣的目的。

  • 安全

在安全方面,HBS 這裡也不必贅述,是一定要保障的。

Web 平台打造

再來看 Web 平台的打造,這是和開發者息息相關的。我們看一個平台的核心能力主要是看四個方面:

  • 實時監控
  • 實時預警
  • 多維分析
  • 領域工具

其中,實時監控與實時預警這兩點是最核心的,這兩點做的好,我們就不用擔心因為錯過了線上的某些問題而導致風險的發生。當我們拿到監控數據之後,對數據進行分析的時候不能一蹴而就,這個時候我們需要有多維的分析手段去提供給開發者做決策。而在分析的過程中,我們需要涉及到 JS 異常、性能等各個領域,在分析的時候也會遇到不同的訴求。所以,我們通過各領域內的工具進行打造,以提升我們整體的對於問題的定位以及分析問題的能力。

前端的守望者:阿里岳鷹 Web 全景監控平台的建設之路 8

上圖為岳鷹監控平台的實時大盤,從圖中可以看到很多監控的指標,比如頁面性能、異常、API、流量等,我們通過大盤就可以對應用的健康情況有一個大致的了解。同時,在報警方面,我們更多會關注報警規則的支撐,還有其自身的實時性、正確性。

前端的守望者:阿里岳鷹 Web 全景監控平台的建設之路 9

岳鷹監控平台有很多的項目,其中性能大盤是其中比較主要的項目之一。我們每一個監控項的閉環裡也需要給開發者提供更細緻的信息。如上圖,圖中的數據會告訴我們應用的整體性能情況,因為如果單獨去看某一個小時、某一天的性能情況可能意義不大,這時就需要進行對比,用監控的數據與數據來源做對比,才能知道整個的趨勢是怎樣的。

最後是代碼追踪,在發生異常後,我們需要知道具體是業務上的哪段代碼出現了問題,這也是比較重要的一個分析維度。而上文提到的代碼分析,通常是沒辦法直接看出問題在哪些堆棧上。這時候,如果我們有 Native 文件,就可以通過一定的映射方式,直接把業務代碼還原出來,並找到具體是哪一段代碼出現了問題,找到代碼後,我們可以直面開發者並給他修復建議。

接入場景

對於上文提到的前端埋點的弊端,通常情況下監控的多為應用級,接入單個應用或單個頁面,我們每新建一個頁面、新建一個應用,就可以讓開發者直接復用我們的監控代碼,把這段代碼植入後就可以進行監控了。在很多場景下還可以對效率加以提升,例如容器級的接入,例如在UC 的內核上面做全方位的自動監控,還有餓了麼APP,因為沒有接內核,直接用Webview 注入我們的JS SDK,以達到自動監控的目的。所以,通過這樣的深度支持,我們在效率方面有了比較大的提升。

除了這兩個例子,在內部我們還有支付寶這樣大體量的業務,支付寶用的就是我們的內核,目前直接做到了對小程序的自動監控,開發者不必手動添加多餘的代碼就可以達到自動監控的效果。還有與釘釘平台的深度合作,釘釘採用了我們 JS SDK 加內核的方案來服務整個開發平台的監控方案。而且,岳鷹在經歷了雙十一、雙十二這些大流量的活動後,也凸顯出了服務大體量用戶的能力。

岳鷹平台的未來展望

前端的守望者:阿里岳鷹 Web 全景監控平台的建設之路 10

目前為止,岳鷹已經能做到實時預警,但未來我們希望可以做到更加智能的預警方式。比如說,有時預警出現一些高峰,當採樣數據不足的時候,是否可以忽略掉,不做噪音的干擾之類的更加智能化的預警。

另一方面,目前前端的技術和框架層出不窮,對於監控平台來說,我們的願景是能夠真切地幫助到開發者,所以,在未來我們還是會對新型的語言框架做進一步的支持,真正的為開發者帶來便利。

總結

前端的守望者:阿里岳鷹 Web 全景監控平台的建設之路 11

上圖為岳鷹平台的產品架構,目前運營平台大概分為這麼幾個部分,還有一些簡單的輔助性功能,最核心的還是監控預警和問題分析方面的能力。我們在每一個場景都提供了比較好的閉環。最後總結一下:

  • Web 監控平台閉環:採集 – 上報 – 解析 – 計算 – 多維分析 – 實時預警
  • 白屏監控原理:頁面加載完成 3s 內無繪製指令
  • 領域工具的打造,可極大提升體驗及問題分析解決的效率

嘉賓介紹

陳周勉,阿里巴巴前端技術專家,目前就職於阿里 UC 事業部,擔任研發效能組的前端負責人。近年來主要專注於雲機以及前端監控領域,已對外推出兩款產品——岩鼠雲設備平台和岳鷹全景監控平台。曾主導部門的前端體系建設,精通 Vue 和 React,在前端架構、工程化、性能等方面有較豐富的經驗。