攜程小程式生態之自動化錯誤預警方案

陶然陶然發表於2023-03-17

   摘要

  攜程小程式自動化錯誤預警方案是一套完整且通用的小程式前端錯誤監控方案。此方案提供小程式錯誤自動採集SDK,並對錯誤所在的頁面路徑進行偏移矯正,能夠準確通知相應的開發負責人;將錯誤資訊分為生產、測試、開發3種階段,根據錯誤發生的階段提供相應的錯誤預警及處理方案;開發負責人只需在小程式管理平臺配置告警所需資訊,即可快速接入、實時監控生產報錯、生成告警通知;原始碼對映能力可以幫助開發者快速定位錯誤原因,提升修復效率。接入此方案可實時捕獲開發環境錯誤,確保在小程式釋出上線前發現並解決業務報錯,可極大地減少線上小程式的錯誤量。

   一、為什麼要做錯誤監控

  攜程小程式產品是to C的,使用者訪問量大,使用的機型和場景複雜多樣;當使用者遇到問題時,我們無法保證所有使用者都及時反饋,且提供明確、詳細的資訊。因此,為了保證系統穩定執行、提高使用者體驗,我們需要主動收集錯誤資訊、實時監控錯誤變化趨勢、及時解決。

  為了提升小程式程式碼質量、守護線上頁面質量,Web前端團隊提出了攜程小程式的小程式錯誤預警方案,可分為4個階段,如圖1所示:  

圖1 小程式錯誤預警分階段圖示

  攜程小程式自動化錯誤預警方案在自動化部署階段將buildId 注入程式碼,並透過固定robotId的方式獲取對應的 sourcemap 檔案;客戶端執行時自動採集錯誤資訊,同時進行埋點上報;服務端處理儲存的錯誤資料,並按照頁面路徑、錯誤型別等維度進行分類;告警平臺將實時監控報錯情況,根據自定義的告警規則給開發負責人傳送告警通知,詳細的方案設計參見圖2:  

圖2 錯誤預警方案設計圖

   二、sourcemap 儲存及對映

  攜程小程式釋出是透過ci工具上傳小程式程式碼實現的。在釋出前,我們會將無線持續交付平臺(Mobile Continuous Delivery,下文統稱為MCD釋出平臺)建立的buildId注入到小程式程式碼中,以供執行時獲取。由於微信不支援透過版本資訊或其他的唯一資訊獲取對應的 sourcemap 檔案,我們設計了一套獲取相應 sourcemap 的方案:

  我們透過固定robotId的方式上傳原始碼,從而獲取對應的 sourcemap 檔案;在成功上傳小程式程式碼後,將延遲5秒後使用ci工具拉取最近一次上傳版本的 sourcemap 檔案;此外,將會比對 sourcemap 的解壓原始檔中buildId與當前上傳程式碼中的buildId是否一致,如果不一致將再次獲取,從而確保上傳的原始碼和獲取的 sourcemap 檔案是匹配的,保證原始碼對映的準確性。

  隨後,將 sourcemap 檔案儲存到攜程的檔案伺服器,並將服務端返回的檔案連結地址、當前的buildId、時間點以及自定義備註等資訊以物件的形式儲存到資料庫中,即可實現buildId與 sourcemap 檔案的資訊儲存及對映。

   三、錯誤採集及日誌上報

  在小程式客戶端執行時,我們會在 wx.onError 和 wx.onUnhandledRejection 的回撥函式中捕獲到所有的錯誤資訊,隨後進行錯誤資訊的篩選、處理和提取。其中,錯誤的關鍵資訊有:pagePath, message, stack等。此時,我們會對捕獲到錯誤時所在頁面的pagePath進行偏移糾正,避免頁面偏移導致誤報的情況。那麼如何實現錯誤偏移糾正和錯誤採集呢?

  首先,在上傳小程式程式碼包前,我們會透過讀取app.json的內容,獲取所有註冊的頁面路徑,並將其注入到小程式程式碼中。接著,在捕獲到錯誤資訊時,我們會對error stack進行解析,從上往下進行頁面路徑貪婪匹配,匹配到的第一個頁面就是發生報錯的頁面。隨後,將錯誤資訊、當前的appId以及釋出時注入的buildId一同透過使用者行為資料採集系統(User Behavior Tracking,下文統稱為UBT)的錯誤介面上報,上傳到UBT的服務端。至此,便完成了一次錯誤採集與上報的流程。

   四、資料聚合

  採集到上報的錯誤資料後,服務端會對資料進行清洗、過濾、聚合等操作,隨後將預處理後的資料存入APM的MySQL資料庫中。透過內部的APM監控平臺主動讀取資料庫中的資料,實現各種自定義維度的資料聚合,比如分別根據部門、客戶端平臺(Platform)、報錯頁面路徑(PagePath)、小程式版本(version)、Top50錯誤型別等維度進行排序並展示資料列表(如圖3)。

  這些處理後的資訊為下文的錯誤告警提供了資料支撐,告警主要依據的是報錯頁面路徑(PagePath)及Top50錯誤型別這兩個維度。  

圖3 APM — 攜程微信小程式JS Error

   五、錯誤實時監控告警

  除了業務主動去APM上實時檢視報錯情況,我們還提供了錯誤告警機制,會在不同階段對採集到的錯誤進行訊息推送提醒,詳細流程如圖所示:  

圖4 小程式錯誤告警流程

  從上圖可看出,錯誤告警貫穿整個小程式的開發流程,共分為三個版本,包括開發版、體驗版以及生產版。錯誤告警服務每隔一段時間輪詢不同環境的報錯資訊(呼叫APM提供的資料聚合介面),若報錯量超過我們設定的告警閾值(詳情可見表1),則會根據錯誤頁面找到對應的Bundle(最小的業務線單位),然後再找到對應的開發人員或管理員(對應關係已在小程式管理平臺中註冊),透過攜程內部溝通工具(下文統稱為TripPal)將錯誤提醒推送給相關人員,在收到資訊後可以透過點選資訊直接跳轉到具體的APM錯誤頁面中,在APM中可以進行錯誤的反查與定位。下表展示了各階段告警配置的詳細情況:  

表1 各階段告警配置

  (1)開發版

  在開發階段,及時捕獲錯誤有助於開發人員第一時間進行修改,因此每隔1分鐘,服務端會獲取每個頁面路徑的報錯量,只要頁面有報錯,將推送訊息至該Bundle的相關人員。  

圖5 開發版告警

  (2)體驗版

  體驗版是一個完整穩定的版本,是可以作為釋出候選的版本,因此對該環境的報錯進行監控是十分必要的。體驗版除了能接收到與開發版一致的錯誤資訊外,還會傳送反饋訊息,由Bundle管理員進行審批,審批的意義在於告知管理員當前要釋出到生產的程式碼中存在錯誤,需要管理員知曉並判斷是否修改,若10分鐘內未處理,將再次發訊息進行提醒。  

圖6 體驗版告警

  在MCD釋出平臺生成體驗碼時,若仍有Bundle未處理體驗版報錯,將在釋出群中再次提醒:  

圖7 MCD構建結果通知

  以上兩個階段都屬於開發測試階段,目的在於將所有的業務報錯資訊都在開發階段暴露出來,然後讓各個業務及時修改,保證發到生產的程式碼沒有業務報錯。

  (3)生產版

  總有意外的情況會導致生產執行出現錯誤,為了更快更全面的感知生產報錯,我們會對生產錯誤進行兩個維度的監控:

  每隔5分鐘,服務端獲取某類錯誤的報錯量超過 100 的頁面路徑,隨即發出通知訊息至相應的開發和管理人員,管理人員此時需要重視下頻繁報錯是否會對生產業務造成影響並給PMO反饋修復的時間以及是否需要緊急釋出。  

圖8 生產版告警(錯誤型別維度)

  每隔1小時,服務端會獲取每個頁面路徑的報錯量,然後聚合到每個具體的Bundle,如果發現Bundle一小時報錯量超過了300,也將傳送告警資訊。  

圖9 生產版告警(Bundle報錯量維度)

  由於通知訊息本身不具備強制性、約束力,因此我們接入了公司的告警治理系統(下文統稱為BigEyes)。生產版報錯將透過BigEyes進行統一通知,如果告警事件未在預設的響應時間內被響應,則進行通知升級,即通知原物件的上級,以此提高業務方的重視程度及故障恢復效率。  

圖10 小程式告警接入BigEyes

  為了便於獨立小程式的接入,在現有方案的基礎上,我們設計並實現了一套通用的可定製化的錯誤告警配置服務。獨立小程式在引用錯誤採集SDK的前提下,透過在小程式管理平臺配置告警所需資訊,包括用於告警的專屬Trippal服務號、開發負責人、不同環境(正式、體驗、開發)的告警閾值等,即可在觸發告警條件時,收到服務號發來的錯誤通知。  

圖11 獨立小程式錯誤告警配置頁面

   六、原始碼對映

  從APM平臺檢視錯誤資訊時,可以透過錯誤的詳情頁面進入小程式錯誤原始碼解析系統。由於我們在錯誤採集時會將buildId和錯誤相關資訊一起上報至服務端,因此錯誤詳細資訊內包含報錯程式碼包對應的buildId(如圖14);在點選錯誤堆疊上的連結跳轉至錯誤原始碼解析系統時,系統將根據buildId獲取到相應的 sourcemap 檔案;隨後,根據錯誤資訊找到對應的 sourcemap 內容、依據錯誤位置進行反解析;最後,使用 Monaco Editor 將原始碼展示在頁面中,開發者可以據此檢視錯誤所在的原始碼位置,從而助力開發者快速、準確定位錯誤原因。  

圖12 小程式JS Error概覽頁面  

圖13 小程式JS Error聚合、分類頁面  

圖14 小程式JS Error詳情頁面  

圖15 小程式JS Error原始碼解析頁面

   七、總結

  自動化錯誤預警方案可以幫助各業務方在開發和測試階段捕獲執行時可能出現的業務報錯,避免此類錯誤釋出到生產環境,從而降低線上的錯誤量。在生產環境可以透過告警機制實時監控錯誤趨勢,當出現告警時可透過原始碼對映系統快速定位錯誤原因、提高開發者的修復效率。

  該方案極大地提升了小程式的執行穩定性,可以有效提升使用者體驗。自主機板小程式接入攜程小程式自動化錯誤預警方案以來,其日均線上報錯量降低了95%左右,受到各業務部門的好評,印證了本方案的可行性和有效性。  

圖16 2022年攜程微信主機板小程式每日錯誤次數統計圖

來自 “ 攜程技術 ”, 原文作者:攜程前端框架團隊;原文連結:http://server.it168.com/a2023/0317/6794/000006794433.shtml,如有侵權,請聯絡管理員刪除。

相關文章