【前端分享】掌門教育自研APM實踐分享

由白玉蘭開源開放研究院指導，聯合掌門教育、聲網、vue北京，舉辦的第二期前端技術分享活動，已於6.19號落幕，如下爲大咖講師們，現場演講的整理稿，感謝你們的支持：

講師介紹

分享嘉賓——劉偉，掌門教育自研APM項目負責人，如下爲劉偉同窗精彩演講的部份內容：

爲何咱們要自研掌門教育本身的APM系統

針對數據分析這塊，掌門教育內部，後端服務使用的是開源的Apache SkyWalking系統，雖然SkyWalking已經提供了很是方便的SDK，能夠知足咱們不少場景下的需求。但對於掌門教育目前的一些定製化的前端業務場景，咱們不少的業務需求依然難以徹底覆蓋，以此咱們前端須要一套本身的APM系統。

目前天眼系統的使用場景

天眼系統主要是針對外部C端用戶信息進行記錄，目前掌門教育已經有400+個前端項目，接入天眼系統的應用數量也有100+，接近全部項目總數的30%，主要覆蓋Web端、H五、App這些應用場景。

掌門教育天眼系統的模塊結構

探針：數據採集、上報是APM系統的發起點，它主要負責在客戶端程序中採集數據，併發送到咱們服務器端的收集器。針對探針的設計，最大的難點主要在於咱們如何去設計，並獲取咱們須要的數據信息，好比跟用戶體驗及其相關的95/99線等等。

收集器、存儲器：收集、存儲器自己只是一個簡單的應用程序，但結合到數據源多樣化的topic類型、龐大日誌量，以及咱們要保持系統的穩定性、可靠性，這就對咱們提出了更高的技術要求。

數據可視化界面：UI系統是咱們另一個很是核心的應用產品，相似咱們常見的PV、UV指標，都須要在這一層中被暴露出去，向咱們的業務賦能這些關鍵數據信息。

天眼系統的輻射能力

異常預警：前端異常告警的概念相對於後端應用來講，理念可能不是很強，好比後端redis-timeout這種異常是很是致命的，前端這樣的相似的場景就比較少。但如今，不少極度影響用戶使用體驗的場景，對於一家互聯網公司來講，也已經愈來愈重要，這就要求咱們可以尋找並提供一種方式、方法去讓前端團隊可以對這些關鍵指標進行預警。

工單追蹤：咱們不少時候，C端用戶會報障過來，過去咱們只能提供後端api的調用鏈來分析問題，但假如用戶App自己出現了問題，好比卡頓等等這樣的問題，那咱們就須要可以獲取到用戶的設備狀況、網絡狀況來進行分析。

業務指標分析：對於前端應用來講，一個頁面內容的渲染、交互，能夠分爲不少細小的過程，好比咱們打開一個新頁面，須要哪些流程進行處理，每個流程的表現狀況如何，這些數據信息若是可以記錄下來，而且進行鍼對性的分析，咱們前端就能夠針對性進行優化。

前端APM重點關注的數據類型

咱們目前APM系統，結合了很是多掌門教育定製化場景的數據類型，這些數據類型可能不必定適合每個公司，這取決於你公司具體業務場景。在掌門技術部，咱們不少的上報信息跟產品、項目是強相關的。

通用性數據類型，咱們包括PV、UV，設備信息，流量信息、系統信息，用戶App先後臺存活信息等等，另外H五、App採集方式的區別也比較大，上報的方式也不同。

數據採集的一些問題和數據上報時機問題

第一個問題是數據源的準確性問題。前端數據源的採集相對於後端，每每受到的影響因素不少，好比後端常見的一些訪問超時，發生的時候就能夠快速的記錄下來，而前端會面臨着延遲的概念，另外前端採集還會面臨不少數據丟失的狀況，這種種因素髮生的機率很是高，這就對咱們前端數據源的採集帶來了不少的挑戰。

第二個問題是數據上報時機問題。對於C端用戶環境而言，咱們的業務交互和採集數據上報都會佔用同一個帶寬資源，咱們必需要保證業務的優先級，儘可能不去影響用戶使用體驗，因此咱們必需要實現必定的調度、控制，好比上報數據間隔變大或者變小，讓它自動化，本身自動去發現何時合適去上報數據，同時咱們也會須要必定的延遲上報能力，看看多少許的狀況下更合適上報，而不是定時、定量去發送。

將來展望

1. 咱們但願可以在數據上報成功率上再進一步，目前咱們的上報成功率大概在98%左右，咱們但願這個數據能夠達到99%以上。
2. 天眼系統研發的初衷，是但願可以補充咱們公司定製化場景下的一些問題，因此咱們也不但願閉門造車，將來，咱們會去跟業務方進行溝通，對接更多的技術、業務需求，最終作到與公司互相賦能。
3. 目前，咱們的Topic數目、日誌量開始慢慢多起來，這麼多的數據量裏面，咱們去作數據信息的檢索，去查某一項的數據，性能上仍是有很大的提高空間，將來咱們可能調研一些其餘方案來解決這些問題。