掌門教育自研APM實際分享

為什麼我們要自研掌門教育自己的APM系統

針對資料分析這塊，掌門教育內部，後端服務使用的是開源的Apache SkyWalking系統，雖然SkyWalking已經提供了非常方便的SDK，可以滿足我們很多場景下的需求。但對於掌門教育目前的一些定製化的前端業務場景，我們很多的業務需求依然難以完全覆蓋，以此我們前端需要一套自己的APM系統。

目前天眼系統的使用場景

天眼系統主要是針對外部C端使用者資訊進行記錄，目前掌門教育已經有400+個前端專案，接入天眼系統的應用數量也有100+，接近所有專案總數的30%，主要覆蓋Web端、H5、App這些應用場景。

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

探針：資料採集、上報是APM系統的發起點，它主要負責在客戶端程式中採集資料，併傳送到我們伺服器端的收集器。針對探針的設計，最大的難點主要在於我們如何去設計，並獲取我們需要的資料資訊，比如跟使用者體驗及其相關的95/99線等等。

收集器、儲存器：收集、儲存器本身只是一個簡單的應用程式，但結合到資料來源多樣化的topic型別、龐大日誌量，以及我們要保持系統的穩定性、可靠性，這就對我們提出了更高的技術要求。

資料視覺化介面：UI系統是我們另外一個非常核心的應用產品，類似我們常見的PV、UV指標，都需要在這一層中被暴露出去，向我們的業務賦能這些關鍵資料資訊。

天眼系統的輻射能力

異常預警：前端異常告警的概念相對於後端應用來說，理念可能不是很強，比如後端redis-timeout這種異常是非常致命的，前端這樣的類似的場景就比較少。但現在，很多極度影響使用者使用體驗的場景，對於一家網際網路公司來說，也已經越來越重要，這就要求我們能夠尋找並提供一種方式、方法去讓前端團隊能夠對這些關鍵指標進行預警。

工單追蹤：我們很多時候，C端使用者會報障過來，過去我們只能提供後端api的呼叫鏈來分析問題，但假如使用者App本身出現了問題，比如卡頓等等這樣的問題，那我們就需要能夠獲取到使用者的裝置情況、網路情況來進行分析。

業務指標分析：對於前端應用來說，一個頁面內容的渲染、互動，可以分為很多細小的過程，比如我們開啟一個新頁面，需要哪些流程進行處理，每一個流程的表現情況如何，這些資料資訊如果能夠記錄下來，並且進行針對性的分析，我們前端就可以針對性進行最佳化。

前端APM重點關注的資料型別

我們目前APM系統，結合了非常多掌門教育定製化場景的資料型別，這些資料型別可能不一定適合每一個公司，這取決於你公司具體業務場景。在掌門技術部，我們很多的上報資訊跟產品、專案是強相關的。

通用性資料型別，我們包括PV、UV，裝置資訊，流量資訊、系統資訊，使用者App前後臺存活資訊等等，另外H5、App採集方式的區別也比較大，上報的方式也不一樣。

資料採集的一些問題和資料上報時機問題

第一個問題是資料來源的準確性問題。前端資料來源的採集相對於後端，往往受到的影響因素很多，比如後端常見的一些訪問超時，發生的時候就可以快速的記錄下來，而前端會面臨著延遲的概念，另外前端採集還會面臨很多資料丟失的情況，這種種因素髮生的機率非常高，這就對我們前端資料來源的採集帶來了很多的挑戰。

第二個問題是資料上報時機問題。對於C端使用者環境而言，我們的業務互動和採集資料上報都會佔用同一個頻寬資源，我們必須要保證業務的優先順序，儘量不去影響使用者使用體驗，所以我們必須要實現一定的排程、控制，比如上報資料間隔變大或者變小，讓它自動化，自己自動去發現什麼時候合適去上報資料，同時我們也會需要一定的延遲上報能力，看看多少量的情況下更合適上報，而不是定時、定量去傳送。

未來展望

1. 我們希望能夠在資料上報成功率上再進一步，目前我們的上報成功率大概在98%左右，我們希望這個資料可以達到99%以上。

2. 天眼系統研發的初衷，是希望能夠補充我們公司定製化場景下的一些問題，所以我們也不希望閉門造車，未來，我們會去跟業務方進行溝通，對接更多的技術、業務需求，最終做到與公司互相賦能。

3. 目前，我們的Topic數目、日誌量開始慢慢多起來，這麼多的資料量裡面，我們去做資料資訊的檢索，去查某一項的資料，效能上還是有很大的提升空間，未來我們可能調研一些其他方案來解決這些問題。