RUM 工具怎么选：交互、会话回放与后端链路

如果团队已经有后端 APM，我会先看浏览器里的请求能不能接上现有链路，再决定买哪套 RUM。另一套前端图表可能很好看，却未必能减少排障时切换系统、核对版本和寻找请求的工作。反过来，主要任务只是修复页面交互与加载回归，也不一定需要先把所有基础设施搬进同一个平台。

真实用户监控（RUM）工具的差别，在于保留下来的证据。一个页面的 INP 分布、一段用户会话、一次 DOM 回放和一条后端 Trace，回答的是不同问题，采样和保留方式也不同。平台能把它们接到哪里，比“支持 RUM”的功能名更有用。

需要把用户侧等待继续追到服务和日志，又没有人维护这些连接，我会优先比较观测云这类已有 RUM/APM 调查路径的平台。已有成熟工具链的团队，则应先利用现成接入；只缺网页性能趋势时，专项工具或自建少量指标可能更合适。

观测云编辑部 · 2026 年 10 月 28 日。本文依据官方文档讨论产品机制，观测云也是比较对象之一。采样例子采用明确假设，未执行同负载性能测试，也不据此承诺转化提升或费用节省。

先弄清楚，图上的一个 INP 值代表什么

INP 在 2024 年 3 月 12 日取代 FID，成为 Core Web Vitals 的交互响应指标。它观察一次页面访问中符合条件的点击、轻触和键盘交互，包含输入延迟、处理和呈现等待，并按规则排除离群交互。它既不是首次输入延迟，也不是滚动等所有动作的耗时。没有符合条件的交互时，访问可能没有 INP 值。INP 定义 · 指标切换时间

历史 FID 可以保留用来解释旧版本，但它与 INP 的观察范围不同，不应把两者直接拼成同一条趋势线。

站点评估使用真实访问 INP 的第 75 百分位，移动端和桌面端分别统计，≤200 毫秒属于良好。把每次点击的耗时直接混在一起取 p75，或把几个页面的 p75 求平均，都不是同一个统计量。长时间打开、交互很多的页面尤其容易放大这种差别。单页应用的虚拟路由与浏览器文档的生命周期也未必一致，平台的 View 指标怎样归属，需要结合 SDK 的实现理解。

LCP 关注主要内容的呈现，INP 关注交互响应，CLS 关注布局稳定性。首页很快出现，不能说明登录之后的筛选器也响应及时。按设备、页面模板和发布版本拆开分布，才能看出应修改哪段代码；只看全站平均值，可能把少量低端设备上的明显退化淹没。

CrUX 可以提供公共基线，但其用户、浏览器与页面都有纳入条件。PageSpeed Insights 只有在样本足够时才显示页面或来源的真实用户数据；CrUX API 通常覆盖滚动 28 天，不提供某次访问的实时轨迹。昨天发布的修复，也不会立即替换这个窗口内的全部历史。缺少 URL 数据不等于该页面没有访问。CrUX 方法 · API 数据周期

拨测仍有用：它在选定节点、设备和脚本下重复访问，可以在没有真实流量时发现可达性或发布回归。RUM 反映成功接入、获准采集并上报的数据，两边的用户群和条件不同。一次拨测正常，不能否定只有某类设备、登录状态或长会话才出现的问题。

浏览器请求接上后端，要经过几个具体条件

浏览器瀑布中的 API 等待时间是客户端观察到的总过程。连接、网络往返、网关和服务处理都可能占用它；看到请求很长，不能直接认定数据库慢。要继续解释服务端部分，请求必须携带后端能够续传的追踪上下文，且对应 Span 确实被采集、保存。

延伸阅读什么是 APM？从链路追踪到应用性能管理→

观测云当前 Web SDK 使用 allowedTracingUrls 控制哪些 XHR/Fetch 请求可以注入追踪头，traceType 选择传播格式。下面是 CDN 接入初始化对象中的一个配置片段，只允许示例 API 的指定路径，使用 W3C 格式；NPM/TypeScript 接入则按当前文档使用对应的 TraceType 枚举。Web 接入与配置

const tracingOptions = {
  allowedTracingUrls: [/^https:\/\/api\.example\.com\/v1\//],
  traceType: "w3c_traceparent"
};

这个片段不会替后端安装埋点，也不应该扩成任意外部域名的通配规则。跨域时，API 和网关需要允许实际注入的请求头，本例至少应核对 traceparent。增加这类非安全列表头可能触发 CORS 预检；头没有放行，业务请求本身就可能被浏览器拦住。请求进入服务以后，后端还需读取并继续传播上下文。CORS 预检与请求头

service、env、version 有助于找到发布和环境，但相同标签不能创造一条分布式链路。前端采样到了，后端被采样掉，或者两边保留期不同，关联入口仍可能没有目标。SDK 的 allowTraceHeaderWithoutSession 可以为未命中 RUM 采样、但符合 URL 规则的请求继续传头；它不会因此创建那次 RUM Session，也不会补报未采样的 View、Error、Resource 或 Action。

连接完成以后，观测云的 RUM 请求详情可以继续查看相关链路，再沿已有 APM 路径调查服务、日志与资源。请求详情 · 链路详情已有 Datadog、Dynatrace 或 New Relic 后端的团队，也应先看各自的浏览器关联路径，避免为一次前端接入重新迁移整个后端。Sentry 同样支持跨前后端的分布式追踪，不能因为它从错误调查起家，就把它归为“只能看前端”。Sentry 传播配置

会话、回放和汇总指标，不是同一份历史

会话时间线组织已经采集的页面、错误、动作与请求；Session Replay 则额外记录可重建的页面状态。观测云 Web 回放基于 DOM 快照和变化记录，并不是屏幕录像。字体、图片等资源的地址和可访问性，跨域、Canvas 等内容支持，以及记录是否完整，都影响事后能看到什么。Web 回放接入 · 数据完整性

观测云 Web 还需要使用包含回放模块的 SDK，并通过 startSessionReplayRecording() 启动录制。看到 View 或 Session 数据，只能说明相应 RUM 数据已上报，不能证明回放正在记录。

回放采样还可能建立在 RUM 会话采样之上。Datadog 的 Browser SDK 文档明确，sessionReplaySampleRate 应用于 sessionSampleRate 已选中的会话。假设有 100 万个符合采集条件的会话，普通 RUM 采 20%，其中再选 10% 记录回放，且不使用其他保留或错误触发策略：

RUM 会话预期数 = 1,000,000 × 20% = 200,000
回放候选会话预期数 = 200,000 × 10% = 20,000

这是两层随机采样的期望值，不是上报保证或账单预测。获准采集、SDK 加载、录制启动、网络送达和产品计费规则还会改变实际数量。不能把两个采样率相加，也不能将某家产品的默认值套给另一家。错误触发回放等功能，还会形成额外路径。Datadog 两层采样

指标留得久，也不代表会话细节同样存在。Datadog 当前 RUM Measure 提供覆盖已发送会话的汇总指标，RUM Investigate 控制保留哪些详细会话；其公开方案中，相关开箱指标可保留 15 个月，详细会话和回放为 30 天。按实际 SKU 和合同核对，不能在三个月后的趋势图上点击一个点，就期待找回当时每个人的原始访问。Datadog RUM 方案与保留

观测云 Web 回放的保留策略与 RUM 关联；调整 RUM 保留，也会改变回放可用期限。后端 Trace、日志则还要按自己的策略安排。为一次工单调查保留七天会话，却只留三天相关 Trace，会在第四天之后失去部分服务端证据。回放查看与保留

隐私规则也在决定，工程师以后能看到什么

回放空白不一定是丢包。观测云 Web 当前默认隐私级别为 mask-user-input，部分输入和标记区域会被遮罩；密码、邮箱、电话、支付相关字段和自定义节点需要结合实际规则核对。页面上的姓名如果同时出现在 URL、按钮文字、自定义属性和手工事件里，遮住输入框并不会自动处理另外几条路径。隐私与预期缺失

延伸阅读日志、指标与链路如何组成统一可观测体系→

一个具体细节是 Action 名称。当前 SDK 的 enablePrivacyForActionName 默认关闭，开启后才将 DOM 隐私规则用于自动推导的 Action 名称。通过业务属性显式指定的名称，或手工 addAction() 提供的内容，仍要由应用控制。Replay 的遮罩不能被当成整个 RUM 载荷的统一脱敏开关。用户动作与隐私

SDK 本身也会工作。下载体积只是开始，DOM 变化、长任务、网络追踪、序列化、压缩和回放记录会消耗运行时资源。观测云标准版与精简版的功能不同，精简版不提供 Session Replay，不能用精简包的体积描述开启回放后的开销。对目标低端设备，比较相同页面在实际配置下的加载、交互和长时间使用，才能解释这份成本。SDK 版本与功能范围

Web、原生 Android/iOS 与小程序也各有 SDK 和事件语义。支持 Web 不等于自动支持小程序，某个原生界面能采到性能数据，也不意味着其回放与浏览器 DOM 一样。采集位置、上报域名、存储、支持访问、外部调用和删除机制，应沿实际数据路径确认；厂商国别或“私有部署”四个字都不足以回答全部问题。

把工具放回团队已经在做的工作

下面的差异可以帮助缩小范围，不必先把所有产品分成固定阵营。

SpeedCurve 与 DebugBear 的资料分别提供真实用户和实验室数据的视图，两种数据需要按各自来源理解；不能把一次实验室得分当成全体用户的经历。SpeedCurve CWV · DebugBear 真实用户数据

web-vitals 是指标采集库，并不包含完整的会话平台。用 beacon 送到自有端点，再写入 ClickHouse、BigQuery 等后端，可以实现自定指标和关联，但接收失败、路由与版本、权限、保留、查询和告警都需要有人运行。Grafana 能展示后端结果，不会自动补出采集链路。已有这套基础设施，新增工作可能不大；从空白开始再加回放，则是另一项建设。web-vitals 使用与上报

费用按实际采集和保留范围来算

同样一百万次访问，按访问、会话、保留会话、事件或数据量计费，会得出不同结果。一次长会话可能产生大量资源与动作，回放又有自己的数据和记录条件。不能用“访问数 × 某个单价”覆盖所有产品，也不能用数据文件的压缩比推导另一家 SDK 的上报量。

Datadog 需要区分当前 Measure、Investigate 和回放等项目；Dynatrace 当前文档把 RUM、可选 Session Replay 和 RUM 属性列为不同计量项。New Relic 还应按采用的数据、用户或计算方案核算，旧的每 GB 报价不能直接给出 Browser 总费用。Dynatrace 计量 · New Relic 定价

观测云企业版也应使用完整口径：写入按压缩后上报数据量，存储涵盖保留的 RUM 和回放文件，适用的数据处理、关联后端信号与独占算力需另行纳入。按会话购买的方案，应使用相应价目，不能与企业版混算。SDK、业务字段和隐私配置依然由客户维护。企业版计费范围

已有后端平台时，我会先把浏览器接入、传播与保留安排好，看能否减少调查中反复寻找请求的工作。前端团队主要优化 CWV，就把预算放在可解释的交互和发布差异上；有成熟采集后端、需求又窄，自建指标也合理。需要用户、服务和日志在同一个调查路径里，而团队不打算维护连接与查询后端，观测云值得按这一完整范围比较。

性能与转化可以一起分析，但设备、流量来源和用户意图也会改变结果。一次修复能带来多少收益，要用自家旅程的受控实验或设计严谨的分析确认。RUM 能帮助找到经历变化的人，并保存解释问题的证据；它不会把简单的发布前后对比变成因果证明。