OneUptime 真实用户监控RUM完全指南OpenTelemetry 分类机制、接入流程与排障实战【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime真实用户监控Real User MonitoringRUM回答的是与合成探测完全相反的问题不是我们模拟的用户体验如何而是真实用户在浏览器与移动端究竟经历了什么。本文基于 OneUptime 官方文档packages/App/FeatureSet/Docs/Content/en/rum/index.md 及其多语言副本 fa/rum/index.md系统讲解 OneUptime 如何借助标准 OpenTelemetry 管线自动发现、分类并聚合 RUM 应用从资源属性分类规则、service.name身份模型、核心功能面板到四步上手流程并结合仓库源码剖析底层实现。读完本文你将掌握让浏览器 / 移动端应用以 RUM 身份出现在 OneUptime 中的完整方法以及排查应用不显示类问题的一线技巧。RUM 是什么真实用户体验 vs 合成探测RUM 的本质是采集真实用户的客户端遥测。你拥有的浏览器或移动应用自行上报其遥测数据——页面加载、路由切换、fetch 请求、运行时错误、Core Web Vitals——而 OneUptime 将这些数据归组为一个个RUM 应用RUM Application供你打开、绘图、搜索并设置告警。与某些需要专用 Agent 或私有协议的产品不同OneUptime 的 RUM复用与后端完全相同的 OpenTelemetry 管线没有独立的 RUM Agent没有专有线上协议wire format只需要将 OpenTelemetry 浏览器或移动端 SDK 指向 OneUptime遥测数据在到达时被分类为 RUM。会话回放Session Replay则是叠加在这一层之上的、独立且可选的能力它有自己的脚本标签与隐私控制详见 会话回放入门。在界面的哪里Resources → Real User Monitoring在仪表盘中RUM 位于Resources → Real User Monitoring。每个 RUM 应用都拥有自己的标签页标签页用途Overview页面访问、错误率、p95 延迟等概览Metrics / Logs / Traces完整遥测浏览器且限定在该应用范围内Clients应用出现过的浏览器平台与设备型号Session Replay / Replay Users会话回放与回放用户Health / Replay Policy / Replay Access Log回放健康度、策略与审计日志项目级设置Owner Rules 所有者规则、Label Rules 标签规则、会话回放总开关位于 RUM 侧边菜单的Settings区块中。应用级管理细节标签、保留策略、归档删除、权限拆分可参考 管理 RUM 应用。分类机制OneUptime 如何判定一段遥测是 RUM这是整篇文档中最值得理解的部分——几乎所有我的应用不显示的问题都归结于此。分类发生在接收ingest阶段按每个遥测批次batch依据资源属性resource attributes判定。判定顺序如下如果资源携带browser.platform、browser.language、或非空的browser.brands中的任意一个该批次归类为浏览器browserRUM否则如果携带device.id或device.model.identifier归类为移动端mobileRUM否则如果携带device.manufacturer且没有host.name或host.id归类为移动端mobileRUM否则不是 RUM——作为后端 Service 处理。第 3 条规则是最容易产生疑问的特例device.manufacturer同时充当主机清单项上物理机器的制造商字段因此只有当资源不携带任何主机身份时它才把批次标记为移动端 RUM。手机永远不会上报host.name或host.id而服务器总是会上报——这正是该信号干净可用的原因。关于主机清单属性可参考 host-otel-collector 文档。分类后的身份service.name一旦批次被分类为 RUM应用的身份就是其service.nameOneUptime 在项目内不区分大小写地查找具有该标识的 RUM 应用Storefront-Web与storefront-web是同一个应用而不是两个找不到时自动创建客户端遥测完全归属于其 RUM 应用永远不会再被列为后端 Service因此不会出现重复计数。从源码看这一身份模型在数据模型层被显式固化。在 RumApplication 模型 中数据库层通过Index([projectId, appIdentifier], { unique: true })强制每个(projectId, appIdentifier)只有一行注释明确写道RUM 以应用service.name为键而非以终端用户设备为键——按设备建行将是一场基数灾难appIdentifier字段的列描述直接注明它来自 service.name OpenTelemetry resource attribute且update权限保持为空——身份字段不允许事后修改否则会孤立所有已按旧标识归档的会话、追踪与录制clientTypebrowser / mobile、sdkLanguage、agentVersion、lastSeenAt、otelCollectorStatus等列分别对应文档中概述页展示的 SDK 语言、SDK 版本与连接状态。资源属性参考表属性是否必需作用service.name是应用身份例如storefront-web。没有service.name就没有 RUM 应用。browser.platform/browser.language/browser.brands面向 Web将批次标记为浏览器 RUM。device.id/device.model.identifier面向移动端将批次标记为移动端 RUM。device.manufacturer面向移动端将批次标记为移动端 RUM除非资源同时携带host.name或host.id。建议同时设置上述两个之一则该规则永不生效。telemetry.sdk.language否显示在概览页例如webjs、swift。telemetry.sdk.version否作为 SDK 版本展示缺失时回退到oneuptime.agent.version。oneuptime.label.name否提升为应用上的项目标签name:value详见 管理 RUM 应用。最常见的错误OpenTelemetry 浏览器 SDK 默认不会添加browser.*属性除非你启用浏览器资源探测器browser resource detector或自行设置属性。只设置service.name会得到一个完全合法的后端 Service而不是 RUM 应用。具体两种正确做法见 浏览器接入通过browserDetector自动探测或直接手动设置browser.language/browser.platform等属性。你能获得什么RUM 应用的核心视图概览Overview页面访问量、错误率和p95 延迟覆盖可自由选择的时间范围配有趋势图另有客户端平台与已录制会话的瓷砖tile。注意所有计数都派生自你的埋点instrumentation发出的 span所以页面访问的含义完全取决于埋点如何上报文档加载、路由变更、交互。Core Web Vitals当 SDK 将指标上报为 metric 时概览卡片会展示LCP、INP、CLS、FCP、TTFB五项指标并给出好 / 需改进 / 差三级评价。OneUptime 会依次探测一组已知指标名取第一个在所选时间范围内有数据的名称。完整的指标名清单、评级阈值与上报代码示例见 Core Web Vitals 指南。日志、追踪与指标完整的遥测浏览器全部限定在当前应用范围内。客户端Clients应用出现过的浏览器平台与设备型号按平台粗粒度聚合绝不按终端用户细分。这与 RumApplicationClientService.recordClient 的实现一致该方法按(projectId, rumApplicationId, clientName)幂等 upsert 一条客户端平台记录只刷新lastSeenAt即一平台一行而非一用户一行。会话回放Session Replay录制用户会话并在回放中与同一会话的错误、追踪与日志并列展示附带可搜索的会话列表以及用于判断录制是否在到达、在哪里停止的 Health 页面。详见 会话回放入门尤其是 观看一个会话。连接状态Connection Status只要遥测持续到达应用显示Connected静默15 分钟后翻转为Disconnected。从源码看这一状态由 ResourceHeartbeat 统一写入lastSeenAt这类活性liveness写入按窗口节流文档说明为每分钟一次因此Last Seen最多落后真实流量约一分钟——15 分钟阈值已内建了这部分余量。此外RUM 应用的otelCollectorStatus、lastSeenAt等列也正对应于此。上手四步让第一个 RUM 应用出现创建遥测接收令牌Telemetry Ingestion Token进入Project Settings → Telemetry APM → Ingestion Keys创建接收密钥并查看 token。该 token 会嵌入页面 JavaScript因此按公开信息对待即可——它仅授予接收权限无法读取项目内任何数据。为应用埋点按 浏览器接入 或 移动端接入 配置 SDK。加载一个页面应用会在第一批遥测到达时自动出现在Resources → Real User Monitoring下——无需手工创建。自动发现逻辑在服务层由RumApplicationService的按appIdentifier即service.name查找或创建实现且查找不区分大小写。可选增强按 Core Web Vitals 上报核心网页指标并按 会话回放入门 叠加会话回放。如果应用没有出现RUM 排障指南 会按照故障实际发生的顺序逐一排查失败模式。从源码理解接收链路与数据约束RUM 之所以能零 Agent、零私有协议地运行靠的是 ingest 侧的开放接入点与严格的基数控制开放接收端点遥测经由 OTLP 端点traces / metrics / logs进入请求头携带x-oneuptime-token。相关接收逻辑集中在 TelemetryIngest 中间件浏览器发起的请求还会校验 Origin 与接收密钥的允许来源防止伪造数据冒充其他来源。模型层的基数护栏RumApplication 模型 的注释明确记录了设计取舍——RUM 按应用而非按设备聚合(projectId, appIdentifier)唯一索引从数据库层面防止重复应用行SchemaMigration 则进一步说明RumApplicationClientbrowser.platform/device.model按平台粗粒度存储。这正是Clients 标签页永不按终端用户细分这一文档承诺的底层保障。连接状态机制如上文所述ResourceHeartbeat 统一负责十二类遥测资源的活性写入通过 Redis 窗口节流与FOR UPDATE SKIP LOCKED保证高并发接收下lastSeenAt写入有界、状态判定可靠。结语OneUptime 的 RUM 能力建立在两个简洁而强力的设计之上复用标准 OpenTelemetry 管线、以资源属性为分类信号。只要在 SDK 中正确配置service.name与browser.*/device.*属性RUM 应用便会随第一批遥测自动出现随后即可使用概览、Core Web Vitals、客户端画像与会话回放等全套视图并复用现有的 Metrics / Traces / Logs Monitor 对客户端体验直接告警。理解分类规则与基数约束就掌握了排查绝大多数 RUM 接入问题的方法论。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OneUptime 真实用户监控（RUM）完全指南：OpenTelemetry 分类机制、接入流程与排障实战
OneUptime 真实用户监控RUM完全指南OpenTelemetry 分类机制、接入流程与排障实战【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime真实用户监控Real User MonitoringRUM回答的是与合成探测完全相反的问题不是我们模拟的用户体验如何而是真实用户在浏览器与移动端究竟经历了什么。本文基于 OneUptime 官方文档packages/App/FeatureSet/Docs/Content/en/rum/index.md 及其多语言副本 fa/rum/index.md系统讲解 OneUptime 如何借助标准 OpenTelemetry 管线自动发现、分类并聚合 RUM 应用从资源属性分类规则、service.name身份模型、核心功能面板到四步上手流程并结合仓库源码剖析底层实现。读完本文你将掌握让浏览器 / 移动端应用以 RUM 身份出现在 OneUptime 中的完整方法以及排查应用不显示类问题的一线技巧。RUM 是什么真实用户体验 vs 合成探测RUM 的本质是采集真实用户的客户端遥测。你拥有的浏览器或移动应用自行上报其遥测数据——页面加载、路由切换、fetch 请求、运行时错误、Core Web Vitals——而 OneUptime 将这些数据归组为一个个RUM 应用RUM Application供你打开、绘图、搜索并设置告警。与某些需要专用 Agent 或私有协议的产品不同OneUptime 的 RUM复用与后端完全相同的 OpenTelemetry 管线没有独立的 RUM Agent没有专有线上协议wire format只需要将 OpenTelemetry 浏览器或移动端 SDK 指向 OneUptime遥测数据在到达时被分类为 RUM。会话回放Session Replay则是叠加在这一层之上的、独立且可选的能力它有自己的脚本标签与隐私控制详见 会话回放入门。在界面的哪里Resources → Real User Monitoring在仪表盘中RUM 位于Resources → Real User Monitoring。每个 RUM 应用都拥有自己的标签页标签页用途Overview页面访问、错误率、p95 延迟等概览Metrics / Logs / Traces完整遥测浏览器且限定在该应用范围内Clients应用出现过的浏览器平台与设备型号Session Replay / Replay Users会话回放与回放用户Health / Replay Policy / Replay Access Log回放健康度、策略与审计日志项目级设置Owner Rules 所有者规则、Label Rules 标签规则、会话回放总开关位于 RUM 侧边菜单的Settings区块中。应用级管理细节标签、保留策略、归档删除、权限拆分可参考 管理 RUM 应用。分类机制OneUptime 如何判定一段遥测是 RUM这是整篇文档中最值得理解的部分——几乎所有我的应用不显示的问题都归结于此。分类发生在接收ingest阶段按每个遥测批次batch依据资源属性resource attributes判定。判定顺序如下如果资源携带browser.platform、browser.language、或非空的browser.brands中的任意一个该批次归类为浏览器browserRUM否则如果携带device.id或device.model.identifier归类为移动端mobileRUM否则如果携带device.manufacturer且没有host.name或host.id归类为移动端mobileRUM否则不是 RUM——作为后端 Service 处理。第 3 条规则是最容易产生疑问的特例device.manufacturer同时充当主机清单项上物理机器的制造商字段因此只有当资源不携带任何主机身份时它才把批次标记为移动端 RUM。手机永远不会上报host.name或host.id而服务器总是会上报——这正是该信号干净可用的原因。关于主机清单属性可参考 host-otel-collector 文档。分类后的身份service.name一旦批次被分类为 RUM应用的身份就是其service.nameOneUptime 在项目内不区分大小写地查找具有该标识的 RUM 应用Storefront-Web与storefront-web是同一个应用而不是两个找不到时自动创建客户端遥测完全归属于其 RUM 应用永远不会再被列为后端 Service因此不会出现重复计数。从源码看这一身份模型在数据模型层被显式固化。在 RumApplication 模型 中数据库层通过Index([projectId, appIdentifier], { unique: true })强制每个(projectId, appIdentifier)只有一行注释明确写道RUM 以应用service.name为键而非以终端用户设备为键——按设备建行将是一场基数灾难appIdentifier字段的列描述直接注明它来自 service.name OpenTelemetry resource attribute且update权限保持为空——身份字段不允许事后修改否则会孤立所有已按旧标识归档的会话、追踪与录制clientTypebrowser / mobile、sdkLanguage、agentVersion、lastSeenAt、otelCollectorStatus等列分别对应文档中概述页展示的 SDK 语言、SDK 版本与连接状态。资源属性参考表属性是否必需作用service.name是应用身份例如storefront-web。没有service.name就没有 RUM 应用。browser.platform/browser.language/browser.brands面向 Web将批次标记为浏览器 RUM。device.id/device.model.identifier面向移动端将批次标记为移动端 RUM。device.manufacturer面向移动端将批次标记为移动端 RUM除非资源同时携带host.name或host.id。建议同时设置上述两个之一则该规则永不生效。telemetry.sdk.language否显示在概览页例如webjs、swift。telemetry.sdk.version否作为 SDK 版本展示缺失时回退到oneuptime.agent.version。oneuptime.label.name否提升为应用上的项目标签name:value详见 管理 RUM 应用。最常见的错误OpenTelemetry 浏览器 SDK 默认不会添加browser.*属性除非你启用浏览器资源探测器browser resource detector或自行设置属性。只设置service.name会得到一个完全合法的后端 Service而不是 RUM 应用。具体两种正确做法见 浏览器接入通过browserDetector自动探测或直接手动设置browser.language/browser.platform等属性。你能获得什么RUM 应用的核心视图概览Overview页面访问量、错误率和p95 延迟覆盖可自由选择的时间范围配有趋势图另有客户端平台与已录制会话的瓷砖tile。注意所有计数都派生自你的埋点instrumentation发出的 span所以页面访问的含义完全取决于埋点如何上报文档加载、路由变更、交互。Core Web Vitals当 SDK 将指标上报为 metric 时概览卡片会展示LCP、INP、CLS、FCP、TTFB五项指标并给出好 / 需改进 / 差三级评价。OneUptime 会依次探测一组已知指标名取第一个在所选时间范围内有数据的名称。完整的指标名清单、评级阈值与上报代码示例见 Core Web Vitals 指南。日志、追踪与指标完整的遥测浏览器全部限定在当前应用范围内。客户端Clients应用出现过的浏览器平台与设备型号按平台粗粒度聚合绝不按终端用户细分。这与 RumApplicationClientService.recordClient 的实现一致该方法按(projectId, rumApplicationId, clientName)幂等 upsert 一条客户端平台记录只刷新lastSeenAt即一平台一行而非一用户一行。会话回放Session Replay录制用户会话并在回放中与同一会话的错误、追踪与日志并列展示附带可搜索的会话列表以及用于判断录制是否在到达、在哪里停止的 Health 页面。详见 会话回放入门尤其是 观看一个会话。连接状态Connection Status只要遥测持续到达应用显示Connected静默15 分钟后翻转为Disconnected。从源码看这一状态由 ResourceHeartbeat 统一写入lastSeenAt这类活性liveness写入按窗口节流文档说明为每分钟一次因此Last Seen最多落后真实流量约一分钟——15 分钟阈值已内建了这部分余量。此外RUM 应用的otelCollectorStatus、lastSeenAt等列也正对应于此。上手四步让第一个 RUM 应用出现创建遥测接收令牌Telemetry Ingestion Token进入Project Settings → Telemetry APM → Ingestion Keys创建接收密钥并查看 token。该 token 会嵌入页面 JavaScript因此按公开信息对待即可——它仅授予接收权限无法读取项目内任何数据。为应用埋点按 浏览器接入 或 移动端接入 配置 SDK。加载一个页面应用会在第一批遥测到达时自动出现在Resources → Real User Monitoring下——无需手工创建。自动发现逻辑在服务层由RumApplicationService的按appIdentifier即service.name查找或创建实现且查找不区分大小写。可选增强按 Core Web Vitals 上报核心网页指标并按 会话回放入门 叠加会话回放。如果应用没有出现RUM 排障指南 会按照故障实际发生的顺序逐一排查失败模式。从源码理解接收链路与数据约束RUM 之所以能零 Agent、零私有协议地运行靠的是 ingest 侧的开放接入点与严格的基数控制开放接收端点遥测经由 OTLP 端点traces / metrics / logs进入请求头携带x-oneuptime-token。相关接收逻辑集中在 TelemetryIngest 中间件浏览器发起的请求还会校验 Origin 与接收密钥的允许来源防止伪造数据冒充其他来源。模型层的基数护栏RumApplication 模型 的注释明确记录了设计取舍——RUM 按应用而非按设备聚合(projectId, appIdentifier)唯一索引从数据库层面防止重复应用行SchemaMigration 则进一步说明RumApplicationClientbrowser.platform/device.model按平台粗粒度存储。这正是Clients 标签页永不按终端用户细分这一文档承诺的底层保障。连接状态机制如上文所述ResourceHeartbeat 统一负责十二类遥测资源的活性写入通过 Redis 窗口节流与FOR UPDATE SKIP LOCKED保证高并发接收下lastSeenAt写入有界、状态判定可靠。结语OneUptime 的 RUM 能力建立在两个简洁而强力的设计之上复用标准 OpenTelemetry 管线、以资源属性为分类信号。只要在 SDK 中正确配置service.name与browser.*/device.*属性RUM 应用便会随第一批遥测自动出现随后即可使用概览、Core Web Vitals、客户端画像与会话回放等全套视图并复用现有的 Metrics / Traces / Logs Monitor 对客户端体验直接告警。理解分类规则与基数约束就掌握了排查绝大多数 RUM 接入问题的方法论。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
代码包深度解析与实践指南)
