到底什麼是 RUM？生產環境如何選擇靠譜的前端 RUM 監控系統

概述

RUM 英文全稱是 Real User Monitoring，它作用是捕獲和分析使用者與網站的所有互動細節，旨在提高網站的可用性、提升使用者體驗。提升網站體驗的方式非常多，可以優化資料庫、優化介面呼叫，那為什麼要 RUM 呢？主要是 RUM 更直接，更直接的反應了使用者如何和你的網站互動細節，通過真實的行為更精準衡量使用者滿意度。

我們來看看 RUM 跟蹤真實的使用者行為到什麼程度？

Datadog RUM 對使用者行為的精準跟蹤

Datadog 有一個 Session Replay 功能，大致原理：通過 UserID 標籤取樣網站鏈路資料，然後在後臺完整回放使用者具體行為：比如先後訪問哪些頁面，點選了什麼按鈕或連結。以時間軸方式回放了整個過程。而且，RUM 上還展示出每次互動產生的效能指標和異常報告。這樣的功能，是不是覺得很實用？是的，在不需要太多技術門檻，你可以很方便觀察起業務系統和使用者行為。

具體影片演示，可以訪問地址

http://www.datadoghq.com/blog/session-replay-datadog/

RUM 可觀測性系統的定位

為了方便大家方便理解 RUM、APM、Observability 概念和他們在 IT 系統穩定性保障的定位，我大致梳理了下面這張體系圖

其實，RUM 目前業界定義略有差異：

• Datadog、OpenTelemetry 趨向於和 APM 做對比，APM 既然重在後端程式的鏈路監控。RUM 就主要特指前端網站的使用者互動行為，所以常規理解，RUM 就是前端監控

• 但譬如 New Relic 沒有提 RUM ，它針對產品使用物件，區分為 Browser Monitor 和 Mobile Monitor。甚至它提出 RUM 本身屬於 APM 的範疇，下面的解釋也是可以理解

RUM is a core feature of  application performance monitoring (APM) .

Real user monitoring is also sometimes known as  browser monitoring because the end user experience happens in the browser. While other aspects of application performance monitoring involve measuring server-side performance (the backend), real user monitoring measures client-side performance—the browser where users interact with your application.

• 因為現在廣泛大前端，除了瀏覽器，還包含移動端小程式、H5，Webfunny、Sentry、騰訊雲其它商業產品把對它們的可觀性統稱前端監控，也並沒有過多提 RUM 概念。移動端本質也是使用者使用的 Application，所以對 Android、IOS 的終端的監控也是 RUM 範疇也不未過

綜上說講，RUM 無論怎麼劃分覆蓋範圍，重點還是在於 Real User ，本文也側重在網站監控，那麼移動端的使用者行為監控，本質也是差不多的。

下面演示可觀測系統下，RUM 和 APM 配合如何做到全鏈路方式追蹤使用者訪問

RUM 現狀

近幾年湧現了許多非常優秀的 RUM 產品，我列舉部分如下

除上面提及產品 ，市面上還有譬如：Arms RUM、騰訊雲前端監控，Dynatrace。限於篇幅和個人瞭解程度，本文不做對比。我主要收錄的維度：

• 產品體驗：側重生產環境的 RUM 功能上易用性、實用性；主要介紹 Session Replay、Synthetic Monitor、錯誤追蹤等功能的支援和對比。

• 使用者行為分析：很多 APM 在生產環境中收集鏈路資料過多，會遇到很多效能問題。特別大型分散式系統中，APM 取樣能力、儲存能力決定 APM 的靠譜程度；

• 資料採集能力 Agent：從 Agent 的技術生態、支援元件、開發框架能力。很多公司生產系統在這個維度就已經做了 RUM 的選型了。比如公司使用了 Nodejs 的 RabbitMQ 客戶端，只有 Datadog 目前友好支援。或者使用 taro 國內受歡迎小程式搭建框架，還只能國內 Fundebug 來支援。

• Source Map 的支援：哪些 RUM 通過 Source Map 技術，實現和如何支援錯誤程式碼定位。

• SPA 的相容：SPA 由來介紹，產品上如何相容 SPA 監控。

• 全鏈路能力：RUM 和 APM 聯動的支援，同時對全鏈路監控給出一些產品選型的建議，和產品體驗感受。

• 中國特色個性化定製：微信公眾號、小程式，小遊戲，支付寶小程式如何做到可觀測。

• 社群和文件支援：產品對應的技術社群成熟度和產品文件的質量；

• 其它：Crash 上報能力，數字大屏，資料取樣能力。限於優先順序和本文篇幅，以後可以做更多相關分享，在此不多做介紹；

產品使用體驗

效能概覽 Performance Overview

Datadog 支援常見的 Real User Monitoring 效能指標採集

1、Google 網站核心指標(LCP、FID、CLS)

2、Top Visit

統計最常訪問頁面，還單獨將非同步 XHR 請求進行統計，對於 web2.0 網站比較友好

3、Resources analysis

總結：介面人性化，指標清晰。而且效能指標的鑽取非常方便。同時上面 Tag Search，Time Line 篩選，也是做到了 To C 產品體驗，相信經常用的人會感覺得很舒服。

使用者會話概覽 User Session

Session Trace

Http Session 會話作為一次使用者訪問行為。一個使用者可能一天當中會有多次 Session 訪問

每次 Session 生產一個 Trace，這個 trace 進行跨程序通訊，也會傳遞給 back-end 程式

通過 RUM、APM 關聯，我們可以完整看到一個 Session 的後臺請求鏈路資訊

從互動來說，Datadog 鏈路甘特圖展示比較完整，和介面體驗非常舒服

Synthetic Monitoring

什麼是 Synthetic Monitoring？和 RUM 什麼關係

從技術方面來講，前端效能監控主要分為兩種方式，一種叫做合成監控 SYN（Synthetic Monitoring），另一種是真實使用者監控 RUM（Real User Monitoring)

合成監控：就是在一個模擬場景裡，去提交一個需要做效能審計的頁面，通過一系列的工具、規則去執行你的頁面，提取一些效能指標，得出一個審計報告

SYN 中比較流行的是 Google 的 Lighthouse

合成監控的優缺點

我們通過下表總結，來看看合成監控的優缺點

• Analyze the root cause of load time spikes with rich waterfall reports on an element level 通過豐富的 DOM 瀑布流報告分析負載時間峰值的根本原因

總結：核心效能指標對使用者體驗影響比較大，比如提到的 Google 網站效能指標 LCP、FID、CLS。RUM 系統都支援自帶 Synthetic Monitoring 功能，尤其 Uptrends 提供的最詳盡，你想得到的它都給你支援了

Uptrends Synthetic Monitoring 工具庫

使用者行為回放 Session Replay

基於一次 HTTP Session 回話，通過記錄 Page Event，將每次 DOM 的渲染記錄下來，從而達到記錄使用者互動行為。目前，Datadog、Fundebug 都支援類似功能。他們底層核心都基於開源框架技術，叫做 rrweb ，一種非常受歡迎用來記錄和回放 Web 中使用者行為的開源專案

http://github.com/rrweb-io/rrweb

我們簡單看看 Datadog 關於 Session Replay 的描述

On the Datadog replay view, the page is rebuilt and the recorded events are re-applied at the right time.
The browser SDK is open source and leverages the open source project rrweb.

從 Replay 的功能體驗來說，Datadog 產品功能體驗最好的。

Session Replay 的作用：

1、定製化分析使用者行為軌跡:比如一個分散式電商系統，我們可以通過一個 User 的訪問活動 Session，看到它具體這次訪問哪些頁面，如何互動，對於呼叫了哪些後臺介面，一目瞭然

2、方便跟蹤具體的異常：因為沒有完善可觀測系統，過去在故障定位中，往往從請求端一個個系統做排查，這樣效率比較低下。而且，有些複雜故障可能由不同條件觸發，某些互動行為正常，某些情況下才出現異常。這就導致線上排查難度極大：測試如果迴歸不到觸發條件，很難復現問題，讓故障定位和排查時間，人力成本急劇上升。

Session Replay 回放使用者訪問電商網站行為

甚至，線上業務系統過於複雜導致短期無法定位問題！這是真實存在的。

總結：Session Replay 是一個非常實用的功能，也體現了可觀性的價值：真正觀察使用者行為，配合 APM 得到完整使用者訪問的全鏈路資訊，基於此，對於故障的根因分析和定位，提供根本性的解決方案

錯誤追蹤和 Crash 上報

錯誤追蹤，RUM 主要指 Js 錯誤彙總和錯誤展示。Crash 上報，一般都是通過 SDK 方式整合。

區別在於 Saas 和私有化部署需不需要走外網的網路差異。

各個 RUM 錯誤追蹤功能，從產品功能佈局，展示上有不同差異，基本上核心統計指標都有。

從細節和功能適用度，能看出簡陋和豐富的區別。Datadog、Sentry 更強，主要從幾個方面：

1、Sentry 在 Error Track 統計專業、應用： 易用統計大屏，清晰從 Project 維度拆解 Error 統計，很方便讓對於系統的研發團隊跟蹤，統計問題。而且，Erorr Track 支援逐級鑽取資料，通過整合 Sourcemap 功能，直到看到錯誤原始碼。

2、Datadog、Sentry 還支援 Error Issue 功能：對於要修復的 Error ，在平臺直接管理 Issue ：1）、支援更新 Error 的狀態，有 Erorr 使用者影響面彙總統計，幫助決策優先順序；2）、可以指派 Error 修復人 Sponsor，類似於 Jira 進行基本 bug 生命週期管理，支援訊息推送

總結：Sentry 在錯誤追蹤和上報做的非常專業，甚至說最好的。這和它本身的產品定位有很大基因關係，它重心就是“”。

SourceMap 技術

什麼是 Source Map

通俗的來說， Source Map 就是一個資訊檔案，裡面儲存了程式碼打包轉換後的位置資訊，實質是一個  json 描述檔案，維護了打包前後的程式碼對映關係

Source Map 的價值

隨著前端專案結構化發展，程式碼越來越龐大和複雜。大部分原始碼（各種函式庫、框架）都要經過轉換，才能投入生產環境

常見的原始碼轉換，主要有這樣一些場景需要

• 壓縮，減小體積

• 多個檔案合併，減少 HTTP 請求數

• 其他語言編譯成 JavaScript

這些場景，都使得實際執行的程式碼不同於開發程式碼，除錯程式碼變得困難重重 Source Map 在即使打包過後的程式碼，也可以找到具體的報錯位置，這使得我們 debug 程式碼變得輕鬆簡單，這就是 Source Map 想要解決的問題

Source Map 演化史

2009 年 Google 在介紹 `Cloure Compiler` 時， `Google` 也趁便推出了一款除錯東西： `Firefox` 外掛 `Closure Inspector` ，以便利除錯編譯後代碼

2010 年，在第二代即 `Closure Compiler Source Map 2.0` 中，Source Map 以 `JSON` 格式作為標準， `mapping` 演算法運用 `base 64` 編碼

2011 年，第三代 Source Map

http://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit#

它脫離 `Clousre Compiler` ，演化成了一款獨立東西，也得到了瀏覽器的支撐。這一版最大的改動是 `mapping` 演算法的緊縮換代，運用[VLQ] 編碼生成[base64] 大大縮小了 .map 檔案的體積

Source Map 的工作原理

核心資料結構

通過 .map 的 Json 檔案描述程式碼對映關係，包含了以下一些資訊：

• version：sourcemap 版本（最新 v3）

• file：轉換後的檔名

• sourceRoot：轉換前的檔案所在的目錄。如果與轉換前的檔案在同一目錄，該項為空

• sources：轉換前的檔案。該項是一個數組，表示可能存在多個檔案合併

• names：轉換前的所有變數名和屬性名

• mappings：記錄位置資訊的字串

• mappings 資訊是關鍵，它使用 Base64 VLQ 編碼，包含了原始碼與生成程式碼的位置對映資訊。mappings 的編碼原理詳解有興趣可以參考

http://www.ruanyifeng.com/blog/2013/01/javascript_source_map.html

Source Map 的原始檔

Source Map 進行 Bug 診斷

有了它支援，我們在鏈路異常資訊中，快速定位到錯誤程式碼，當然前提原始檔上傳 Source Map

如何上傳 Source Map

RUM 提供了以下常見 Sourcemap 支援方式

1. API 上傳

2. 提供命令列形式 批量上傳

Fundebug 還支援前端 UI 上傳 Source Map

如果你是希望多 Source Map 原理和配置瞭解更多，推薦可以看看 Fundebug 中文文件

http://docs.Fundebug.com/notifier/javascript/sourcemap/

總結：當然，Source Map 雖然很好，但是如果 RUM 是 Saas 或者非私有化部署，是否考慮程式碼完全性問題，Sentry 和 Fundebug 也都做了一些安全支援。

比如 Sentry 支援在相應的 Project 設定 Security Token，如果外網訪問 Source Map ，都必須提供 X-Sentry-Token   ，當然 Sentry 控制檯請求時，自動帶上這個 Security Token

GET /assets/bundle.min.jsX-Sentry-Token: {token}

相比 Fundebug，就處理簡單一些：通過修改網頁伺服器或者代理伺服器的配置，僅允許 Fundebug 下載 Source Map 檔案即可。這種擴充套件性就比較差，配置也比較麻煩，而且還要看元件支不支援。例如專案使用 Nginx 作為代理伺服器

在 Nginx 配置檔案中新增 location 模組，使用正則表示式匹配 .map   檔案。其中/dist/為 Source Map 檔案所在目錄路徑

<code data-type="codeline">location ~ ^/dist/(.+)\.map$ </code><code data-type="codeline">{</code><code data-type="codeline">	allow 120.77.45.162;    </code><code data-type="codeline">  allow 120.79.16.115;</code><code data-type="codeline">  deny all;    </code><code data-type="codeline">  proxy_set_header X-Real-IP $remote_addr;</code><code data-type="codeline">  proxy_set_header X-Forwarded-For $remote_addr;    </code><code data-type="codeline">  proxy_set_header Host $host;    </code><code data-type="codeline">  proxy_pass http://192.168.59.225:8000;</code><code data-type="codeline"> }</code>

資料採集能力 Agent

New Relic

http://docs.newrelic.com/docs/release-notes/new-relic-browser-release-notes/browser-agent-release-notes/

3 個月左右做一次更新頻率

Added NetworkInformation attributes to LCP & FI. January 6, 2022

Agent 資料採集支援了很廣泛的 JS 框架：React、Angular、AngularJS、Backbone、Ember

、Vue、Meteor、Zepto、Jquery 等

Fundebug

半年做一次更新

Datadog

datadog Agent 探針都做了開源，而且迭代速度非常快。幾乎半個月一個版本，主要迭代目標是為了支援更多的元件和框架

http://github.com/DataDog/dd-trace-js

簡單看看它一次典型更新到底做了什麼，比如 2022-06-09 更新：

Bug Fixes

koa: fix middleware overwriting route of actual route

aws-sdk: fix complete event running in wrong async context

Improvements

http: report the User-Agent header in  http.useragent tag by default in web traces

mysql: add support to dynamically set service in  mysql and  mysql2 plugins

• 修復 NodeJs 的 Koa 框架，亞馬遜雲 SDK 整合 Bug

• 支援 Mysql 外掛裡動態設定 Service 屬性

amqplib: fix incorrect  this  reference when the plugin is disabled

elasticsearch: fix elasticsearch plugin re-normalizing its configuration on every query

• RUM 支援 elasticsearch 搜尋外掛、NodeJs 的 MQ 中介軟體 Rabbitmq 外掛

可以看到，Datadog Agent 支援元件非常豐富和廣泛，遠遠超過其他 RUM 平臺能覆蓋前端元件範圍，這是 Datadog 全世界廣泛客戶群的一個重要原因吧

OpenTelemetry

另外思路：專注於資料採集，儘量相容和支援廣泛的元件和主流框架，這一點不限於 RUM，包括 APM、NPM 等等核心可觀測模組

本地核心庫：

半個月更新一次

http://github.com/open-telemetry/opentelemetry-js/releases

第三方外掛庫：生態內開源組織和商業平臺主動貢獻

阿里雲、亞馬遜雲都來擁抱生態，貢獻平臺級元件庫

http://github.com/open-telemetry/opentelemetry-js-contrib/releases

非常強大、豐富的元件查詢庫，我們可以簡單看看哪些 RUM 元件目前 OpenTelemetry 在貢獻

http://opentelemetry.io/registry/?s=&component=&language=js

監控告警能力

http://docs.datadoghq.com/monitors/create/types/real_user_monitoring/#overview

告警型別

• 基於 RUM 時間 event 一定時間內觸發前端事件統計

• 基於 facet ：facet 指的特別 Tag 標籤，比如瀏覽器型別，伺服器環境(env),只要是能篩選出來的 Tag，都可以基礎之上進行 count ，做報警閾值

• 基於度量的監控: 篩選存在的 Facet 標籤屬性值，給定一定閾值進行預警觸達。為此，提供常見的度量範圍：(min, avg, sum, median, pc75, pc90, pc95, pc98, pc99, or max).

報警方式

亮點：Fundebug 本土化，支援報警訊息源比較多，還支援自定義 Webhook 送達

使用者行為分析

埋點能力 RUM Event

SDK 探針釋出，使用者可以根據自己的需求，建立不同的埋點，選擇不同的圖形在資料看板中來展示分析資料。

資料大屏，和 RUM 非常用價值的漏洞模型。這塊相對來說，獨立第三方 RUM 做得比較通用，比如 Webfunny，它還支援專案、團隊、分組的管理，這讓 RUM 使用者分析在業務系統分析更加清晰

建立點位欄位--建立點位--建立 SDK--建立專案--建立卡片--引入探針--分析資料

Webfunny 新增探針 SDK 檔案，作為資原始檔引入

<script src="xxxxx/sdk.js"></script>

在指令碼 SDK 中，新增點位值事件監控

//測試資料 const data = {    	age: 20,      name: '張三'}
//資料上報, 其中10 表示點位值 _webfunnyEvent[10].trackEvent(data);​

Webfunny 新增曝光和點選埋點

<code data-type="codeline"><!--曝光埋點--></code><code data-type="codeline"><li _webfunny-eo='{"pointId":10, "Doratest":"adwq", "name": "hahaha"}'>我是曝光埋點示例</li></code><code data-type="codeline"><!--點選埋點--></code><code data-type="codeline"><li _webfunny-ce='{"pointId":11, "Doratest":"adwq", "name": "hahaha"}'>我是點選埋點示例</li></code>

RUM Visualize

轉化漏斗：Funnel 功能

Datadog 支援動態的組合 View，生成想要的漏斗轉化模型，對於資料分析非常的實用和強大

http://docs.datadoghq.com/real_user_monitoring/explorer/visualize/#timeseries

比如，下面例子，把使用者端到端的介面訪問以工作流方式平鋪展開，統計各個階段訪問頻率，

完成一個業務系統的訪問漏斗，同時 Datadog 自動計算了中間各個階段的轉化率

Datadog 靈活生成的漏斗模型

強大的擴充套件性 Facet 和 View

在 RUM 各個產品都會生成自己一定特色的資料大屏，這個沒有絕對誰出的資料更好結論。

一方面，大家最關心資料檢視，一般多少有不同檢視支援

另一方面，更看中檢視是否可以動態配置，滿足個性化需求。就像上面 Datadog 的漏斗模型，

需要平臺支援資料模型底層的擴充套件性，讓資料大屏可以動態配置，生成想要的資料檢視。這裡，就不深入擴充套件，只重點提交 Datadog 這方面資料模型設計是很強的：

通過通用的 Facet 標籤、Measure 度量組合成不同的 View，進而展示出豐富的 Funnel 、Timeseries、Distributions 等等資料檢視

Timeseries 時序圖：給定時間週期，視覺化關心效能指標，支援 Facet 篩選

Distributions 分佈圖：給定度量範圍，統計某些效能指標的分佈範圍，支援 Facet 篩選

產品選型

Case By Case 不按場景選型，都是無意義。

是否需要全鏈路監控能力？

常規的 RUM 功能來說，Fundebug、uptrends 並不比商業平臺 Datadog、New Relic 弱，相反在某些功能上還要比他們做得更細、支援更多。比如 Uptrends 提供很多 RUM 實用小工具

這裡面非常清晰認知了，既然 Fundebug、uptrends 產品專注定位在 RUM，如果你只是想要做一些前端監控，並不需要了解 APM 功能，那你就是他們的精準客戶。比如他們典型客戶往往：

1、前端團隊：開發除錯，故障定位，一定程式使用者互動行為分析

2、一些只偏重前端業務的系統，比如 h5 小程式、Web 小遊戲等

當然，越複雜業務系統往往後端服務越重要。再加上如今的微服務、容器化普及，單單 APM 系統只能窺見業務系統冰上一角，而且很難感知使用者行為。一旦系統出現問題，如何定位故障在哪裡？到底該看 APM 還是 RUM？因此，做到全鏈路可追溯就太重要了

自己試用，不能只看 PPT 和 Demo 演示

很多可觀性功能，使用結合自己專案部署驗證，這裡面坑比較多。很難靠前期設想就能夠滿足場景，比如說考慮重點兩個維度

1、是否 RUM 能完整覆蓋業務系統所有元件和框架，這是前期極其容易掉坑環節，如果選型對自己系統框架不去完整做確認，上了以後才發現不支援是很頭疼的問題

2、針對業務系統可能得效能環節，要求對客觀性系統做適當壓測驗證，這種東西 PPT 和文件是看不出來的

全鏈路監控能力

Fundebug、Webfunny 本身產品定位，專注 RUM，不支援全鏈路功能。

Sentry 這樣產品，雖然也有 APM 探針，但是產品更側重 Error Track，產品並沒有支援全鏈路異常分析，各種異常分佈在 Project 分開管理。

Datadog、New Relic 本身商業化可觀性平臺，對全鏈路支援越來越多，以後優先順序越來越高

RUM 和 APM 的聯動

Datadog 下 RUM、APM 聯動，我們可以很清晰看到前端 Web App 、後端服務 Back Services 的消耗時間佔比，RUM 入口通過檢視"Traces"，很方便看到完整全鏈路概況。

通過"Jump to Replay"，我們還可以復現使用者整個訪問行為。

通過 RUM 和 APM 的聯動，實質通過鏈路的 Span 關係，關聯前、後端檢視，達到整個系統可觀性的初衷

Correlate data collected in front end views with trace and spans on the back 

Datadog 中 RUM 通過 SDK 方式關聯 APM 系統例項

import { datadogRum } from '@datadog/browser-rum'datadogRum.init({    	applicationId: '<DATADOG_APPLICATION_ID>',      clientToken: '<DATADOG_CLIENT_TOKEN>',      ...otherConfig,      service: "my-web-application",      allowedTracingOrigins: ["http://api.example.com", /https:\/\/.*\.my-api-domain\.com/]})

關於全鏈路監控，其實 RUM 和 APM 聯動只是一部分，只限於 Traces 的範疇。核心還包含 Traces 和 Logs 聯動，Metrics 和 Trace 的捆綁等等。這個限於篇幅，以後再深入分享。

我們看看通過 Datadog 實現一個完整閉合場景，展現強悍的可觀測監控能力：

1、假設我們做一些核心效能指標監控預警，比如 RUM 響應時間設定最長閾值。配置 Datadog 告警事件，一旦發生，Datadog 會推送結果

2、通過告警結果，關聯鑽取響應的全鏈路服務

通過告警資訊提示和連結，我們鑽取對於的鏈路看看具體訪問情況

3、 通過上圖，清晰標示出了鏈路中哪個 Span 的閾值發生了異常，馬上定位到故障

SPA 監控支援

什麼是 SPA

SPA（single-page application），單頁應用 SPA 是一種網路應用程式或網站的模型，它通過動態重寫當前頁面來與使用者互動，這種方法避免了頁面之間切換打斷使用者體驗在單頁應用中，主要典型考慮手機端應用程式。所有（ HTML 、 JavaScript 和 CSS ）都通過單個頁面的載入而檢索，非同步區域性重新整理頁面模組，不會出現整個頁面跳轉。我們熟知的 JS 框架如 react , vue , angular , ember 都屬於 SPA

MPA（MultiPage-page application），多頁應用，每個頁面都是一個主頁面，都是獨立的當我們在訪問另一個頁面的時候，都需要重新載入 html 、 css 、 js 檔案。多用在網站

SPA 和 MPA 原理

單頁應用與多頁應用的區別

對 SPA 支援

在 SPA（Single Page Application）單頁面應用中，頁面只會重新整理一次。傳統的方式只會在頁面載入完成後上報一次 PV，而無法統計到各個子頁面 PV，也無法讓其他型別日誌按子頁面聚合

New relic 詳盡文件配置和完整的支援，針對 SPA 頁面的兩種處理方式

• 開啟 SPA 自動解析

• 通過 SPA API 方式，手動上報

http://docs.newrelic.com/docs/browser/single-page-app-monitoring/get-started/introduction-single-page-app-monitoring/

Datadog、OpenTelemetry、Fundebug 也對 SPA 不同程度支援，相對體驗沒有 New Relic 好

中國特色

公眾號、小程式等監控

因為國內微信、支付寶龐大使用者群。公眾號，小程式，小遊戲在終端應用程式是非常龐大的市場佔有率。它們底層基於 Web + Native 實現，因為其技術、產品特殊性，國內的 RUM

Fundebug、Webfunny 專門做特殊支援。主要體現兩個維度：

技術支援

底層實現的監控，比如 Fundebug 算是比較豐富，支援一些常見框架監控，下面例子

Fundebug 關於微信小程式監控整合

比如上圖對 taro 框架整合監控，taro 是 github 上比較受大家歡迎的小程式開發框架

http://github.com/NervJS/taro

開放式跨端跨框架解決方案，支援使用 React/Vue/Nerv 等框架來開發微信/京東/百度/支付寶/位元組跳動/ QQ 小程式/H5/React Native 等應用

監控大屏

Webfunny 開發的微信小程式數字大屏

http://www.webfunny.cn/demo/bigScreen.html?projectName=%E5%B0%8F%E7%A8%8B%E5%BA%8F%E6%B5%8B%E8%AF%95&showType=allData

部署能力

私有化部署

Webfunny 、Fundebug、Sentry 都支援私有化部署，單獨的 RUM 售價非常便宜

Sentry、Webfunny 完全開源

Saas 部署

Datadog 、New Relic、Fundebug、Sentry

總結：Sentry、Datadog 開源業界很有口碑，通過 Sentry 私有化、Saas 部署都非常成熟

國內 Fundebug、Webfunny 私有化部署客單價很實惠

八、社群和文件支援

技術文件

Datadog、New Relic、Webfunny、Fundebug 文件中心完整豐富。同時 Datadog、New Relic 在網上搜索一些問題，都能找到合適的解決方案，這對於維護者來說是非常有價值的。好的產品文件，也有助於我們瞭解產品的內部執行原理。

商業產品開源貢獻：

Webfunny 完全做了產品開源版本，國內很多前端監控開發在用，一直持續更新中

http://github.com/a597873885/webfunny_monitor

而且提供通用私有化部署方案

Datadog 開源探針都做了開源，Github 口碑也是不錯

推薦總結：要上生產環境，我們往往希望系統是可控的，完善、成熟的技術文件對於選型來說，是一個很基本的要求。開源還有一個額外的好處，就是程式碼的開放性，不用擔心黑盒的情況存在。如果團隊技術能力足夠強，也能自己 Fix 問題。

社群生態

開源產品一大優勢在於開放性，主要體現社群和技術支援上。 比如 Webfunny、Opentelemetry 國內都有活躍的社群，大家在社群上尋求幫助和交流產品問題，而且社群上都有核心的開源負責人答疑解惑，這本身也是一種友好的技術支援。

Webfunny & OpenTelemetry 微信群

技術支援

開源產品，本身自帶社群屬性，遇到技術問題尋求支援時，整體流程會更高效，但是解決問題速度和反饋因不同團隊的精力而異。國內，RUM 產品體系認知不多，社群生態比較弱，沒有特別推薦的技術社群。 在國外 OpenTelemetry 顯得更活躍。

在商業 RUM 裡，Datadog 藉助 Slack 方式技術支援做得特別好：既有內容沉澱，使用者接入門檻比較低。更重要，還能更好提煉客戶需求。

Datadog RUM 技術社群

總結

我們從幾個維度介紹、對比了主流的 RUM 產品，總結了一些實際場景下的選型建議。

在過去我曾參與過 RUM 產品自研，也曾部署在其業務系統。關於 RUM 產品價值和如何選型問題，其重要還是基於場景化：每個公司 IT 系統既有通用性，也有其自身業務特性。而且，系統複雜度各不同，前端專案要求度也不盡相同。比如 To B 和 To C 的前端體驗，是不同產品邏輯。採用哪一種 RUM 方案，是否需要做全鏈路監控，要不要考慮 SPA 的問等等。都是在考慮當前最合理的方案，而不是最完美的方案。也許，很多複雜的功能並非你想要的。希望我的分享能幫助你，也歡迎大家留言提問。

作者介紹

蔣志偉，愛好技術的架構師，先後就職於阿里、Qunar、美團，前 pmcaff.com CTO，目前 OpenTelemetry 中國社群發起人， http://github.com/open-telemetry/docs-cn 核心維護者

歡迎大家關注“OpenTelemetry” 公眾號，這是中國區唯一官方技術公眾號