前端監控體系建設思考——前端研發體系

前端監控示例圖，來自 Real User Monitoring for improving frontend performance | Atatus Browser

前端監控系統設計簡介

監控的分類

按照常見的部署架構能夠將監控分爲如下幾類：

• 前端應用監控
• 後端服務監控
• 底層運維監控

每一層的監控的側重點都有所差別，本篇文章把範圍限定在「前端應用監控(不含node，node實際上能夠歸爲‘後端服務監控’)」。

前端監控系統定義

前端應用程序監視是一個相對較新的術語，用於描述開發人員，工程師和產品全部者用來跟蹤，維護和修復Web應用程序，本機應用程序和網站的工具。前端應用程序監視與更典型的應用程序性能監視工具（或APM）不一樣，由於它們專一於最終用戶看到的內容，而不是託管應用程序或網站的服務器能夠檢索的事件。 from Front-End Application Monitoring

監控的通常過程與各環節的技術選型

爲何監視對前端很重要？

若是你不能衡量它，那麼你就不能管理它。If you can't measure it, you can't manage it. ——德魯克

前端通常是用戶使用的第一道坎，任何前端的問題均可能致使業務的不可開展，進而影響公司收入、客戶滿意度等等。產品須要瞭解用戶體驗、開發人員須要瞭解服務的性能情況和可用性情況。

監控系統的三個關鍵點

日誌(Logging)

關鍵特徵：離散事件

日誌是有必定格式的離散事件信息集合，用於記錄事件發生的原始記錄、重現應用內部的狀態轉化。例如：接口請求日誌（DNS解析事件、響應時間、成功與否等）、主動上報的用戶行爲日誌。

日誌是監控的基礎，若是沒有日誌也不存在監控。典型的日誌解決方案是ELK Stack。阿里雲上對應產品SLS。

度量(Metrics)

關鍵特徵：數據可聚合

度量，也常被稱做指標，是一段時間內組成單一邏輯尺度、計數器或者柱狀圖的原子，度量的典型特徵就是由可聚合的數據組成。例如：能夠將傳入的HTTP請求的數量建模爲一個計數器，經過簡單的加法就能夠彙總其更新。

追蹤(Tracing)

關鍵特徵：請求圈選

「追蹤(Tracing)」是監控的一個重要組成部分，在現在的分佈式微服務體系結構中變得愈來愈重要。全鏈路的應用監控中，「追蹤」用於請求圈選並展現用戶使用服務的整個過程的堆棧信息。現在一個服務基本是微服務的形式進行調用、部署則是分佈式的，「追蹤」的實現須要經過traceId才能將全鏈路的日誌串起來。例如：

• 前端進行接口請求時，加上在請求header上requestId；
• 接着後端服務A接收到到請求記錄當前requestId，開始處理請求；
• 後端服務A調用依賴服務B，服務B記錄requestId並處理......

從示例能夠看到，經過requestId能夠將一個請求的全部調用鏈路串起來，方便問題排查。

開源的Tracing系統表明有zipkin，openTracing，jaeger。

監控什麼？

錯誤監控

• 全局js報錯(包含catch捕獲)
  • 單個錯誤上報
  • 錯誤/PV佔比
• 網絡請求
  • 設備網絡錯誤
  • HTTP異常狀態碼（例如：40一、40三、413等）
• 接口成功率
  • 調用次數
  • 接口成功率
• 自定義錯誤

性能監控

• 白屏時間
• 首屏時間
• 頁面徹底加載時間
• 靜態資源加載耗時
• UA佔比

業務監控

• PV/UV
• 業務轉化
• 用戶體驗
• 用戶行爲

市面上常見的前端監控產品

ELK Stack

ELK提供了日誌記錄和彙總功能，將其緊緊地放置在可聚合的事件空間中，可是彷佛在其餘域中不斷積累了更多功能，將其推向了中心。

阿里雲ARMS

應用實時監控服務 (Application Real-Time Monitoring Service, 簡稱ARMS) 是一款應用性能管理產品，包含前端監控，應用監控和Prometheus監控三大子產品，涵蓋了瀏覽器，小程序，APP，分佈式應用和容器環境等性能管理，能幫助你實現全棧式的性能監控和端到端的全鏈路追蹤診斷， 讓應用運維從未如此輕鬆高效。 from 應用實時監控服務ARMS - 阿里雲

Sentry

Sentry is an open-source application monitoring platform that helps you identify issues in real-time. from Sentry Documentation - Docs

Sentry 是一個實時事件日誌記錄和聚集的平臺。其專一於錯誤監控以及提取一切過後處理所需信息而不依賴於麻煩的用戶反饋。

CAT — 實時應用監控平臺

CAT（Central Application Tracking）是一個實時和接近全量的監控系統，它側重於對Java應用的監控，基本接入了美團點評上海側全部核心應用。目前在中間件（MVC、RPC、數據庫、緩存等）框架中獲得普遍應用，爲美團點評各業務線提供系統的性能指標、健康情況、監控告警等。自2014年開源。 from dianping/cat: CAT

實戰經驗與最佳實踐

告警分級與響應預案

通常狀況下，咱們須要根據SLA對不一樣的告警進行分級，同時不一樣優先級的告警須要制定不一樣的響應預案。

通常公司會制定4種等級的告警：

• P0: 高優告警
• P1: 中優先級
• P2: 低優先級
• P3: 信息類警報

就時間而言，P0的SLA是分鐘級別、P1的SLA是小時、P2的SLA是天、P3的SLA則沒有時間限制。

響應預案也是很關鍵的，提早制定好預案能夠更加快速的響應告警。

全鏈路監控須要依賴traceId

示例：根據eventId調出全鏈路日誌，來自： Why and How to Test Logging

通常狀況下，traceId是由後端本身生成的前端並不用關心這個traceId，只有在請求異常的狀況下後端會返回這個traceId給前端作排查之用。在分佈式架構中，這個traceId一般是由一個統一的服務頒發的，以保證全局餓的統一性。

因爲前端日誌中缺少traceId，此時前端後端的監控是割裂的。通常狀況下，前端的js錯誤也不須要traceId，經過查看請求參數（設備號UUID、用戶ID）就能夠定位到發生問題的用戶及其設備。

有些場景下，須要打通前端後端的日誌。這時候只能前端使用uuid工具生成一個traceId並經過請求header傳給後端，後端會使用traceId來標記整個服務調用鏈路。這個方案有個缺點：不能保證traceId的全局惟一性。

數據的採樣率

通常咱們在接入一個監控平臺的時候，首先要考慮到上報數據是全量的仍是部分採樣的，由於數據量大小影響數據的準確度。

什麼時候採用「部分採樣上報」？

若是是像淘寶那樣前端頁面訪問量每個月超過百億（根據淘寶月活用戶估計）的，若是全量上報數據可能對數據存儲會產生很是大的壓力。這時，採用「部分採樣上報」是不錯的選擇，數據量夠大的狀況下，樣本也能反應總體。

什麼時候採用「全量上報」

• 數據量小時
• 必須全量上報時

告警的準確度

• 數據量過小致使指標波動幅度大。例如：10個請求中1個失敗，那麼成功率直接降低10%，觸發告警。解決方案：將策略的統計時間拉長，單位時間內至少保證100條以上的數據。
• 噪聲數據干擾告警。例如：同一用戶一直上報問題數據，數據量達到直接影響總體數據。這時告警不能反映大盤。

理清核心指標

相似二八定律，20%的核心指標須要咱們花80%的時間關注。

• 核心業務接口成功率
• 靜態資源大盤
• 錯誤率(Error/PV)

結合大盤看數據

結合大盤看數據，大盤穩則小比例的問題影響不大。好比：出現某個市範圍的「運營商DNS劫持」問題，這個市的數據一會兒掉到正常水位下面，可是大盤仍是沒有啥問題的。這時候，影響面是比較小的。

實時告警的重要性

問題的發生會影響業務的開展，所以，告警的及時性很是重要。大多數的平臺的告警都會有所延遲，若是延遲超過20分鐘，就可能嚴重影響業務（好比：外賣服務的午高峯）

hash路由的影響

不少前端服務會採用hash路由，要注意的一點是：通常頁面pv不會根據hash路由進行區分，多個路由的數據上報要手動進行標記區分。

數據（採集）隱私問題

• 採集須要合規。如今國內立法要求採集用戶數據須要通過用戶贊成，同時採集過程當中違規採集用戶隱私數據也面臨法律風險。
• 存儲須要保障數據的安全。
• 使用數據須要保護用戶隱私。可使用差分隱私方式來保證我的隱私。

監控可視化

可視化面板讓監控變得更加直觀，也下降的用戶上手難度。相似Grafana的監控面板是很重要的。

告警策略配置能力

實際上，前端對告警策略配置能力要求不高。下面幾個策略能力基本知足全部的須要：

• 絕對值。PV絕對值、請求時長等
• 環比/同比。接口成功率同比、PV環比之類。
• 佔比。「Error數/PV」等

核心基礎數據

• 用於識別用戶的數據
  • 用戶跨平臺惟一ID
  • 業務的userId
• 用於識別設備的數據
  • 用戶設備的UUID
  • 瀏覽器UA
  • 軟件版本
• 用於識別數據來源的數據
  • utm_source, utm_medium
  • 不一樣部門、不一樣產品線的標識

不一樣規模的團隊（公司）如何進行監控選型？

• 大公司（阿里、美團點評級別）
  • 裏通常團隊都是採用公司統一的監控平臺進行接入，方便快捷，隊伍比較龐大的BU也會選擇本身作一套本身BU業務定製的監控平臺。之前我所在BU的前端團隊差很少30幾號人，咱們選擇本身搭建監控平臺，開發維護（採用ELK+node埋點轉發+前端採集SDK）平均須要1個全人力投入。
• 中小型公司（相似摩拜之類）
  • 中小型團隊相似大公司裏面的一個BU，一半會本身搭建一套監控平臺（實際上搭建一套基礎監控平臺很簡單，採用開源輪子幾天搞定），不少團隊會選擇使用開源的Sentry、CAT、Grafana、ELK進行再次包裝。
• 小型公司（10-50左右）
  • 直接使用免費的平臺（Sentry、阿里雲ARMS免費版）是比較直接的，或者直接把開源項目在本身的機器上跑起來、不作額外改造也是比較靠譜的。

---

參考資料

• Front-End Application Monitoring
• Peter Bourgon·度量，跟蹤和日誌記錄
• 揭開神祕面紗的監視：有關日誌記錄，跟蹤和指標的指南| 技術信標
• Logs and Metrics - Cindy Sridharan - Medium
• Mon-ifesto第2部分：警報和圖形-資本一技術-中
• 7 天打造前端性能監控系統 - FEX
• 前端異常監控解決方案研究 – 騰訊CDC