靠 Grafana 吃飯的第十九天 - 你監控過你的前端嗎? - Real User Monitoring

16th鐵人賽 grafana grafana scenes grafana faro rum

ysl0628

團隊Grafana 科研遠征小隊

2024-10-03 12:04:33

187 瀏覽

分享至

前言

在軟體開發領域中，我們經常聽到 DevOps、SRE 或後端團隊需要監控服務運行狀況、系統流量和資源使用量等。這種監控或可觀測性通常涵蓋從請求到達伺服器到伺服器回傳響應的整個過程。然而，對於前端工程師來說，當我們注重於網站畫面及邏輯開發的同時，是否也應該關注前端服務的運行狀況呢？例如網站加載速度、錯誤率和使用者操作行為等指標，都是前端工程師需要密切關注的。由於前端應用程式的運行無法完全依靠後端伺服器進行監控，因此前端監控成為了一個獨特而重要的領域。本文將深入探討前端監控的概念、重要性以及相關技術，幫助前端工程師更好地理解和實施前端可觀測性。

何謂前端監控?

要了解前端監控，需要從 RUM (Real User Monitoring) 的角度切入。RUM 是一種效能監控流程，用於收集有關使用者與應用程式互動的詳細資料，例如：點擊、輸入、導覽等行為，乃至於請求開始和速度，這些資料可以幫助我們了解使用者的使用情況，以及追蹤並衡量應用程式中的終端使用者體驗，包括網頁元素的加載時間、頁面是否有錯誤，以及 AJAX 和 HTTP 請求所需的時間等等，另外還可以利用 RUM 更好地了解使用者如何與網站互動，對於行銷或是整個應用程式的優化有更多的參考價值。

RUM 的作用原理

RUM 主要是應用程式效能監控 (Application Performance Monitoring，APM) 的核心功能之一。而使用者體驗主要發生在瀏覽器中，因此也會被稱為瀏覽器監控，雖然 APM 的其他部分涉及測量 Server Side 的效能（後端），但 RUM 主要衡量 Client Side 的效能，即為使用者與應用程式互動的瀏覽器端。

RUM 最常實作的方式是透過在網站中埋入一段 JavaScript 程式碼，這種方式稱為 Instrumentation（儀表化），這段程式碼會在頁面加載時執行，並持續監控使用者的行為和效能指標。以下是 RUM 的基本運作原理：

💡NOTICE
儀表化 (Instrumentation) 是指在軟體系統中插入特定的程式碼，以監控和收集軟體運行時的資料。這些資料可以幫助開發者即時監控，並用於分析和優化軟體的運行狀況。

埋入程式碼：
- 開發者在網站或應用中插入 RUM 相關的 JavaScript 程式碼。
- 這段程式碼通常在頁面加載時就會執行，才能確保完整捕捉使用者的行為。
管理 User Session：每次使用者訪問網站或應用程式時，埋入的程式碼會開始執行並檢查是否已存在 session。如果是新使用者或舊 session 已過期，程式碼會創建一個唯一的 session ID；如果存在有效的 session，程式碼會識別並使用該 session。這個 ID 用於追蹤該使用者在一段時間內的所有操作。當使用者未與應用互動超過預定時間，session 將自動結束，並且下次操作會生成新的 session ID。
捕捉使用者行為數據：一旦 session 被確立，當使用者與網站或應用程式進行互動時，程式碼會記錄與該 session 相關的多種行為數據，包括：
- 頁面加載時間（如首次渲染時間、完全加載時間）
- 使用者操作（如點擊、滾動、頁面導覽）
- 資源加載（如圖片、CSS、JavaScript 檔案）
- AJAX 請求和回應時間
- JavaScript 錯誤
事件觸發和批量傳送：收集的數據會根據特定事件進行數據傳輸
- 當使用者觸發操作（如點擊、頁面切換）或發生錯誤時，數據會立即傳送至監控伺服器。
- 大多數數據會被批量處理，以優化網路使用和減少伺服器負載。
數據傳送到監控伺服器：捕捉到的使用者行為數據會被打包成網路請求（通常是 AJAX 或 HTTP 請求），並傳送到後端的 RUM 監控伺服器。這些數據包含 User Session 的所有相關資訊。
數據處理與視覺化：監控伺服器收到數據後，會進行處理、聚合和分析，將原始數據轉換為有意義的效能指標和洞察。這些結果通常會在監控平台的 Dashboard 上視覺化呈現，供團隊進行效能優化和問題診斷。系統還可能基於這些數據建立告警機制，在出現異常時及時通知相關人員。

RUM 的指標與功能

了解 RUM 的實作原理後，我們可以更深入的了解 RUM 提供了哪些指標以表示使用者的體驗：

效能監控：利用四種 Timing APIs (Navigation Timing API、Performance Timing API、Resource Timing API 和 User Timing API) 和 cookies 收集客戶端效能數據，包括檔案加載和卸載時間、整體網頁效能、瀏覽器加載操作，以及 Google 的 Core Web Vitals 指標：
- 頁面加載時間
- 首字節時間（TTFB）
- 首次內容繪製（FCP）
- 最大內容繪製（LCP）
- 首次輸入延遲（FID）
- 累積布局偏移（CLS）
單頁應用程式（SPA）效能：追蹤 SPA 的效能表現，包括初始頁面加載和路由變更的效能細節。
錯誤追蹤：捕獲 JavaScript 錯誤和失敗的網絡請求，以識別影響使用者的問題。
使用者行為：RUM 追蹤使用者的點擊、滾動和表單提交等互動，以了解使用者如何瀏覽和使用網站。
基本使用者資訊：包括瀏覽器類型和版本、裝置類型、操作系統以及基於 IP 地址的地理位置等資訊。
對後端發送的 API 請求的 Metrics 數據：包括 API 請求的時間、成功率、錯誤率等。
頁面相關的資訊：包括 URL、頁面資源等。
網路連結相關的資訊：包括 DNS 解析時間、連接時間、傳輸時間等。
分散式追蹤：追蹤使用者與網站互動的完整路徑，包括跨多個服務和網站的互動。

額外提供：

支援：提取與某一 user session 相關的所有資訊來排除問題（如 session 持續時間、瀏覽的頁面、互動、加載的資源和錯誤）。
告警：RUM 系統可以設置為在某些效能閾值被突破或錯誤率激增時發送告警。
Session Replay：捕捉並視覺化重現使用者的網頁瀏覽體驗。

為什麼需要前端監控?

在應用程式開發中，所有元素，包括基礎設施、微服務、瀏覽器和行動端體驗，最終都旨在為終端使用者創造卓越的體驗。問卷調查和 A/B 測試雖能提供部分見解，但無法像 RUM 一樣提供全面、即時且持續的使用者體驗洞察。使用者會在幾秒內放棄加載緩慢或有錯誤的網站，糟糕的體驗還會引發連鎖反應，損害品牌聲譽。因此，即時了解終端使用者體驗的工具至關重要，否則等到客戶抱怨或放棄時再行動已為時過晚。

在 2023 年 ObservabilityCON 大會上，Grafana 團隊強調了 RED 指標的重要性，並指出「Humans are impatient」使用者是容易不耐煩，因此服務的運行狀況和使用者體驗密切相關，更直接影響業務成敗。Amazon、Google 等公司證明了反應時間延遲與業務績效的顯著關聯，甚至毫秒級延遲也會造成損失。

💡RED 指標
是 Weave Cloud 在 Google 的四個黃金指標原則基礎上，結合 Prometheus 和 Kubernetes 容器編排管理實踐後，進一步細化和總結出的方法論。它包括請求數量 (Rate)、錯誤率 (Error) 和延遲時間 (Duration)，這些是衡量服務效能的關鍵指標，能幫助我們快速識別和解決問題，確保使用者獲得最佳體驗。

同時團隊也提出了「Performance Golden Rule」，由網站性能優化專家 Steve Souders 提出，表示使用者感知到的 80-90% 響應時間發生在前端。當後端負載較低時，前端處理時間對效能影響更大，強調前端效能優化與後端同樣重要。

而 Google 在 2017 年的研究發現，頁面加載時間從 1 秒增至 10 秒，跳出率增加了 123%，且頁面元素從 400 增加至 6,000，轉化率（Conversion Rate）則下降了 95%，因此前端效能對於使用者體驗和業務成果有著舉足輕重的影響。

另外開發者常常會遇到一個問題，就是當前端出現問題時，我們無法透過後端的監控系統進行排查，例如：點擊按鈕後沒有任何反應，這時後端的監控系統不會有任何錯誤訊息，因此我們需要一個前端的監控系統來幫助我們診斷問題。在成千上萬的使用者中，我們無法得知是哪個 User 遇到了什麼問題，因為大多數的 User 只會說『你們的網站壞掉了』，也不可能請 User 遠端螢幕或是截圖，這時候開發者需要盲目通靈來排查各種狀況，這是非常低效且不確定的。但若是透過前端的監控系統，開發者甚至能夠在 User 客訴回報之前就先一步發現問題，這不但能夠提升 User 的體驗，也能夠提升開發者的效率。

前端監控的工具

瀏覽器內建工具：
- 使用瀏覽器性能 API（如 Performance API、Navigation Timing API）收集效能指標
- 實現全局錯誤處理器來捕獲未處理的異常
第三方分析工具：
- 集成如 Google Analytics、Mixpanel 或自定義事件追蹤
- 採用專業的前端監控服務，如 New Relic Browser、Datadog RUM
效能分析工具：
- 使用 Lighthouse 進行網站效能、可訪問性和最佳實踐分析
- 利用 WebPageTest、PageSpeed Insights 進行更深入的效能分析
錯誤追蹤和 Log 結合：
- 採用如 Sentry 的錯誤追蹤服務以及 session replay 工具
可觀測性工具：
- 利用 OpenTelemetry 收集、處理和導出遙測數據資料
- 使用 Grafana 等工具進行將數據資料視覺化分析

前端監控的優點及挑戰

Real User Monitoring (RUM) 不僅僅是一個技術工具，它還是一項策略資產，許多團隊可能尚未啟動效能監測的功能，但卻需要行銷策略而進行使用者的資料收集，這默默地已經深入了 RUM 的一部分。以下包含技術及營運方面的優點為讀者們分析：

提升使用者體驗：RUM 提供即時且深入的洞察，了解使用者如何與網站或應用程式互動，幫助企業識別痛點、優化流程，進而提升整體使用者滿意度。
加快問題解決：傳統效能監控工具無法捕捉真實世界中的使用者問題，而 RUM 能夠快速檢測並解決效能瓶頸、錯誤及可用性問題，縮短停機時間，提升系統可靠性。
提升轉化率：在競爭激烈的電子商務和線上服務中，每一秒都至關重要。RUM 幫助識別並解決影響使用者體驗的效能問題，例如頁面加載緩慢或結帳延遲，從而提升轉化率，帶來正向的業務效益。
數據驅動決策：RUM 生成寶貴的使用者行為、偏好和平台效能數據，為決策者提供洞察，幫助在功能優化、基礎設施投資和數位策略上做出明智選擇。
主動效能優化：RUM 讓企業從被動解決問題轉變為主動優化效能。通過分析使用者互動和效能指標，企業可以在問題擴大前發現潛在瓶頸，進行策略性改進和資源分配。
客製化內容與功能：RUM 提供使用者在數位平台上導覽的洞察，了解最受歡迎的內容與功能，幫助企業根據使用者喜好體驗，提供更符合需求的服務。
成本優化：RUM 精準定位效能低下的環節，無論是精簡伺服器使用、優化程式碼，還是識別延遲的第三方服務，RUM 都能有效降低基礎設施成本。

挑戰

當公司的產品或服務進行 RUM 的目的，除了上述的所有介紹外，還有希望將服務以端到端的方式進行監控，因此會需要將前端的 RUM 與後端的 APM 進行整合，而有一個在建立統一的遙測資料標準的工具 - OpenTelemetry，其中 OpenTelemetry Browser 的前端函式庫實現中表示為還處於早期階段，因為要在變化多端的瀏覽器環境中制定通用的規範是非常具有挑戰性的。

可能會面臨有些資料類型不完全適合追蹤模型，例如頁面 session 可能持續數小時，難以表示為跨度；使用者互動的表示方式不明確，可能作為無持續時間的事件或觸發其他操作的跨度；還涉及推送通知和跨 iframe 消息等事件觸發問題。此外，網頁和行動裝置數據模型雖有部分重疊，但也存在瀏覽器頁面視圖和行動應用啟動等差異，因而需定義因果關係以連接前後端事件。然而，瀏覽器的 API 支援不足，如無法讀取資源的 Response Header，進一步加大了實現的難度。

RUM 的最佳實踐

設定明確的目標和指標：訂定的目標需要可量化，並使用數據結果來實現。例如縮短頁面加載時間、降低錯誤率或提高使用者滿意度等。
優先考量關鍵使用者路徑（Critical Path Method, CPM）：優先監控應用程式中最重要的使用者路徑，例如：專注於優化註冊流程、產品搜索或結帳流程等核心操作。
實施合理的儀器化：在網頁或應用中謹慎添加 RUM 標籤，避免不必要的腳本，並確保與網站架構一致。使用異步加載以減少對頁面加載時間的影響。
定期審查和分析數據：安排定期檢查 RUM 數據，了解使用者趨勢、效能指標和潛在問題。
監控第三方服務：監控第三方服務的效能，如分析工具、廣告或社交媒體整合，這些服務可能影響網站效能，RUM 能精確找出並解決這些問題。
整合 APM 和 Log 解決方案：將 RUM 數據與 APM 工具和 Log 系統集成，能提供數位生態系統的全貌，結合使用者端和伺服器端的指標來全面解決效能問題。

筆者語錄
經過這一篇文章，我們從 RUM 的介紹到實際的應用，以及最後的最佳實踐，希望能讓讀者對 RUM 有更深入的了解。在回顧於前言中的那張圖，現在普遍已經將 server 端的監控及可觀測性都有了相當的認知以及標準規範，然而前端的監控卻依舊是許多開發者容易忽略且陌生的。而最原始的想法是，既然我們開發了前端的應用程式，那麼我們就應該要對自己的產物負責，並且有更多的掌握度。希望可以透過這篇文章讓我們一起把圖中那兩段紅字的區域填滿。