奧推網

選單
遊戲

神策資料王朋:如何搭建一套高可用的前端異常監控系統?

本文根據神策資料資深前端研發工程師王朋在神策「大資料技術系列直播課」第二季“前端專題”第四講的直播整理。

本次分享主要分為三大部分:前端異常監控概述,異常監控的背景意義,以及做一個前端異常監控的核心問題;然後針對 Sentry 監控平臺,詳細闡述其功能與系統架構;最後透過案例的接入,體驗前端異常監控的實踐與落地。希望本次直播分享能夠給大家提供一些思路上的啟發。以下為正文。

一、前端異常監控概述

1. 異常監控的背景

神策資料是一家大資料分析和營銷科技服務提供商,主要做 ToB 業務,工程師所處理的大部分線上問題都來自於工單。目前,在該場景中存在著許多痛點,比如相容性問題很難排查,介面報錯難復現,問題發現不及時、客戶反饋又比較緊急等,這是在解決客戶問題的過程中經常出現並且令人頭疼的問題。

2. 異常監控的意義

伴隨著網際網路科技的迅速發展,前端技術的使用場景越來越複雜,各種小程式、H5、APP、Web、瀏覽器型號、手機機型,以及使用者網路速度的差異,都可能對我們的業務帶來影響。在諸多因素的影響下,要想保證業務的穩定性、使用者體驗一致性,只有透過前端監控才能多維度的進行全面覆蓋。

3. 異常監控的階段

前端監控一般包括行為監控、異常監控、效能監控,這裡我們主要討論異常監控。大多數情況下,一個完整的異常監控大致可以分為下面四個階段:

(1)異常採集

我們要做到高效、準確、全面的捕獲異常,上報資訊儘可能的自動化,避免不必要的程式碼入侵。要在採集內容的全面性和效能之間做取捨,但要確保當異常出現的時候,能夠根據異常的具體資訊來定位問題。對於採集的內容,我總結了下面四個方面。

(2)資料儲存

當異常資訊上報到後端服務中的時候,後端需要按照一定的規則,對資料進行清洗、過濾和儲存,更重要的一點是要考慮到服務的高可用。

(3)統計與分析

能夠根據上報的異常資料得出深層次的多維度資訊,可以透過預先設定的指標條件對異常資訊進行自動化的計算分析,當超過一定閾值時能夠自動觸發告警。另外,透過系統提供的視覺化面板,使用者可以手動分析,方便發現和定位問題。

(4)報告與告警

可以設定具體的告警規則、渠道、級別,告警的渠道可多樣化,如郵件、簡訊、微信、電話等。對於異常統計資訊的推送,可以做到日報、週報、月報、年報的自動生成並推送給相關的群組。

二、Sentry 監控平臺簡介

1. Sentry 是什麼

中文翻譯過來是哨兵的意思,官網給的解釋是:Sentry is a realtime event logging and aggregation platform。 At its core it specializes in monitoring errors and extracting all the information needed to do a proper post-mortem without any of the hassle of the standard user feedback loop。

即 Sentry 是一個實時的事件記錄和彙集的平臺,它專注於錯誤監控以及能夠自動的提取所需的事件進行處理,而不需要使用者麻煩的反饋。

2. 為什麼選擇 Sentry

(1)Sentry 是近兩年非常火的監控系統,與其它競品相比,可以看到其下載量是穩步上升的。

(2)引入 SDK 的包體積非常小,打包後只有 20k。

(3)100% 開源,效能卓越,易於擴充套件並進行二次開發。

(4)支援 SaaS 版和私有化部署。

(5)支援多個第三方整合,如 GitLab、GitHub、jira、WebHook 等。

3. Sentry 功能架構

下面是 Sentry 的整體功能架構圖,包括異常詳情、異常管理、效能監測、以及可擴充套件能力。在服務部署方面,它支援 SaaS 版和私有化部署,私有化部署能夠有效、全面保證資料的安全。除此之外,Sentry 還具有效能監控的能力,它包括自動監測和手動監測,並對效能監測的結果進行視覺化的展示。

4. Sentry 核心架構

下圖為 Sentry 的核心架構圖,它也是整個 Sentry 儲存和讀取事件的一個流程,是一個讀寫一致性模型,保證了資料讀寫更強的一致性。

Sentry 從客戶端接收事件後,會執行一系列的非同步處理,在事件儲存到 ClickHouse 之前,會將事件插入到 Kafka 主題中,消費者從該主題中讀取並以批次插入的方式寫入 ClickHouse。事件儲存到 ClickHouse 後, Sunba Event Consumer 會進行廣告,透過另外一個 Kafka 主題(commit log topic)來傳遞。同步消費者會同時讀取事件主題和提交的日誌主題,同步消費者會在內部執行狀態機,該狀態機會跟蹤提交日誌的最大偏移,只要有新的事件提交就會消費,經協調處理,執行後處理任務,這就是 Sentry 的核心架構,也是一個讀寫一致性模型。

三、Sentry 監控實戰

1. 私有化部署

Sentry 支援私有化部署,可以使用 Docker-compose、K8S 的方式部署在自己的伺服器上。為了保證服務的高可用,當訪問量激增的時候不至於被流量壓垮,我們採用了 K8S 叢集化的部署方式。

採用的是一主多從的 K8S 叢集部署模式,透過 Helm 對 Sentry 進行部署,整體叢集架構如下圖所示。

2. 專案接入

官網提供了多種語言的 SDK 接入方式,按照文件說明就能夠順利的接入,具體的接入步驟這裡不做贅述,整個的接入流程可參見下圖。

如上圖所示,首先會將前端打包好的資源(JS/CSS/Images/Font)上傳到 CDN。當異常發生時,接入 SDK 的客戶端會自動的將異常資訊上報到 Sentry 服務,Sentry 服務會對資料進行清洗,並將異常資訊實時的展現在後臺管理系統上,開發就可以視覺化的檢視異常的詳細資訊。另外,你可以將自己程式碼的 sourceMap 上傳到 Sentry 服務,這樣開發就可以定位到異常的原始碼位置。

隨著 Web 應用朝著富客戶端方向的發展,前端程式碼的複用性、可用性、一致性會越來越重要,因此搭建一套高可用的前端異常監控系統必要性愈發凸顯。

點選連結可下載完整版演講 PPT:

https://sensorswww。datasink。sensorsdata。cn/t/EMr