隨着微服務架構的流行，服務按照不同的維度進行拆分，一次請求往往需要涉及到多個服務，在發生故障時難以準確定位。因此，需要一些可以幫助理解系統行爲、用於分析性能問題的工具，以便發生故障的時候，能夠快速定位和解決問題。全鏈路監控組件就在這樣的問題背景下出現了。
騰訊 NOW 直播相比其他直播平臺雖然起步較晚，但是成立三年以來， IVWEB 團隊在對業務進行優化的同時，在實踐中不斷沉澱，沉澱出了一套比較完善監控方案。讓我們一起來看，IVWEB 團隊是如何利用該方案在大前端場景下既提升自身業務問題的解決效率，又降低維護難度的？
騰訊高級 Web 前端工程師何方舟老師將在 12月20日～21日舉行的 GMTC 全球大前端技術大會 (深圳站) 上分享《NOW 直播在大前端時代下的監控體系建設》。InfoQ 在會前採訪了何方舟老師，讓我們一起來看 IVWEB 團隊是如何實現大前端監控解決方案的？希望給正在實踐全鏈路監控的你帶來一些參考。
InfoQ：請您簡單介紹下自己以及所負責的工作。
何方舟： 我是何方舟，來自騰訊 IVWEB 團隊，2016 年加入騰訊，先後參與 NOW 直播 SDK、手機 QQ 附近動態、騰訊直播等與直播相關的泛娛樂產品的 Web 前端開發。除了業務需求開發之外，在團隊技術建設上負責團隊性能優化、Node 服務建設、監控體系的搭建，以及前沿技術 PWA、WebAssembly 等在實際業務中的落地。
InfoQ：作爲前端監控開源項目 Aegis 作者，請您簡單介紹下這個項目的背景及意義。
何方舟： Aegis 的含義爲宙斯盾，旨在提供一套開源且功能完善的一站式前端監控解決方案，目前團隊內有 5 名成員在共同維護。
在聊 Aegis 之前，我想先介紹一下 Aegis 的前身 BadJS。
BadJS 是一款騰訊在 2015 年推出的前端異常監控開源方案，在當時的業務環境下 BadJS 很好地承擔了業務中監控異常的任務。但是隨着業務發展團隊擴張，我們也面臨了更加多元化的業務環境。此時，單一的異常監控能力，並不能快速地幫助我們發現和定位問題。我們嘗試在業務中引入了其他工具來幫助解決這個問題，這導致我們的監控體系變得越來越臃腫，項目維護難度增大，降低了研發效率。
在調研行業內其他的監控方案後，我們並沒有發現符合我們要求的解決方案，在和公司其他團隊交流後發現，大家也有遇到同樣的困擾。考慮到我們團隊本身就有維護 BadJS 的經驗，於是我們決定對 BadJS 進行二次開發，提出了 Aegis 前端監控方案。將前端監控中所需要的異常監控、測速服務、性能分析以及流水日誌能力等整合到唯一平臺，降低接入成本， 提供維度更加豐富的查詢手段，幫助開發者快速準確的發現和定位問題。
InfoQ：在 NOW 直播的監控體系建設中遇到的最大的挑戰是什麼？是如何解決的？
何方舟： 我們遇到的最大挑戰應該是監控平臺太多。
騰訊針對前端的監控系統非常繁多，但各個平臺功能點側重點又不一致，以前面的提到的 BadJS 爲例，它只關注異常錯誤監控，如果要接入測速，接口成功率等監控，又需要接入其他平臺。導致前端監控接入開發成本高，工具使用繁瑣。在新人入職、項目交接時，理解這些平臺各自存在的意義，開發的同學叫苦不迭。
在騰訊提倡開源協同的背景下，公司層面也開始建設統一的監控平臺。我們團隊和騰訊雲合作，以業務方真實遇到的業務監控痛點出發，統一整合了各種監控平臺能力，Aegis 就是其中的一個成果。
InfoQ：在 NOW 直播的監控體系中，目前性能的優化成果有哪些？
何方舟： 第一，我們完成了上報端的 SDK 重構，使用 TypeScript 重寫，測試覆蓋率 100%。同時 SDK 做到了 Web、小程序、React Native 的三端同構，極大地節省了我們在多端開發效率。
第二，做到了無開發侵入性地上報。通過針對性地分析了技術方案的一些共性，首先統一了我們的上報標準，定義了關鍵節點的上報，如加載成功率、接口失敗率等。同時，我們在團隊內推廣統一開發腳手架，內置上報埋點，再結合瀏覽器或其他平臺和開發框架提供的 API，減少了開發接入成本。
第三，打通了客戶端日誌，結合對客戶端能力的擴展，做到了 C 端的全鏈路日誌，客戶端同學和 Web 同學都可以分析對方日誌，提高了問題定位速度。
InfoQ：您認爲大前端時代下監控面臨的挑戰是什麼？我們該如何應對？
何方舟： 我認爲如何合理地收集到準確的數據，是大前端時代下監控面臨的一個挑戰。
大前端時代，各團隊的業務往往會覆蓋移動 Web、Hybird App、PC Web、React Native、小程序以及一些自研的動態框架。單純平臺內的一些數據並不能反映出整個應用上面的情況，開發者應該熟悉全鏈路的架構，才能制定出正確的數據上報標準。
以首屏時間來說，傳統的首屏打點計時，是從頁面加載到完成作爲標準。但是啓動 WebView 以及用戶點擊後的一些前置操作（如鑑權校驗等）也會有明顯的耗時，部分低端機型這些部分耗時甚至會超過 3s。這部分耗時瀏覽器本身是無法獲取的，所以我們需要多方協作才能拿到準確數據。
另外，單用戶的訪問鏈路往往會橫跨多個平臺。在追蹤還原問題的時候，問題根源可能是由上下游聯動產生。各平臺本身會有一套監控體系，但是由於平臺差異，形成了日誌孤島。其次，由於平臺時間的差異，再對跨平臺日誌進行關聯時，存在日誌亂序的情況，無法還原用戶的真實操作路徑，進一步降低了排查效率。所以，打通不同的平臺，形成統一的上報標準也是我們需要應對的問題。
InfoQ：在 NOW 直播的監控體系建設中，有沒有什麼通用的業務場景經驗是其他監控可以借鑑的？
何方舟： 總結下來有兩個點是可以和大家分享的。
第一，統一全平臺的上報標準。結合具體的業務場景下（比如 SSR 場景和非 SSR 場景，SPA 和 多級頁面）制定相應的上報點規範，定義關鍵節點。如打開成功率、渲染成功率以及接口耗時規範等。同時，定期對日誌內容進行 Review， 杜絕日誌上報中無意義或含義不明。
第二， 降低監控侵入性，避免手動埋點式的上報。這一點非常重要。從我們以往的經驗來看，依賴手動上報的監控方式，經常會出現線上問題發生後，才發現忘記上報。其次，由於項目交接、技術方案變更、新維護者對架構不熟悉等問題導致手動上報數據不準確。所以，做到無開發侵入性的上報，讓監控在開發層面對使用者透明非常重要。
InfoQ：NOW 直播的監控體系未來有什麼發展路徑？
何方舟： 總的說來現有的監控體系已經比較完善，我們也在持續深挖監控體系中的一些點。
第一，對於監控系統來說，數據收集、上報行爲本身還有進一步的優化空間。例如，最近我們在 HTTP2 的基礎上部分灰度了 QUIC 協議，請求延時降低了 10% 左右。
第二，全鏈路日誌建設，目前我們打通了 C 端的日誌。接下來，如何結合公司後臺服務的全鏈路日誌服務，打通後臺服務日誌，是我們要解決的問題。
最後一點，提升平臺幫助定位問題的效率。我們已經嘗試在使用 AI 對線上問題做一些更深維度的分析，做到智能化的問題聚類。
活動推薦
在即將到來的 GMTC 深圳 2019上，何方舟老師還會具體分享到，大前端時代下監控面臨的挑戰、如何降低開發人員對監控上報的抵觸以及 Aegis 監控方案詳細介紹。讓正在學習全鏈路監控的你，瞭解大前端監控體系的內容與作用、預防與排查常見問題。希望騰訊 NOW 直播的監控案例爲你提供新的思路。
除了何方舟老師的分享，本次 GMTC 全球大前端技術大會（深圳站）2019 我們還設置了小程序挑戰與應對、音視頻技術、Serverless 實戰、測試與安全、大前端工程化、Flutter 實戰、新興編程語言、團隊建設與管理等熱門技術專場。