Skip to main content
Flashduty RUM 提供了从数据过滤、告警分级到 Flashduty 告警处理的完整链路。合理配置这一链路，可以有效降低告警噪音，让团队专注于真正重要的问题。 本文将介绍 RUM 告警配置的核心原则和典型场景方案，帮助您快速减少无效告警干扰。
本文涉及的过滤和分级配置均在控制台「应用管理」中完成：选择目标应用，点击左侧「告警设置」即可配置。详细配置说明请参考 Issue 告警。
2026-03-13-15-08-11

​
告警处理链路

RUM 告警从 Error 产生到通知到人，经过以下四层处理： 配置时建议从上到下依次设置：先过滤噪音，再分级告警，最后在 Flashduty 侧做精细化处理。

​
第一步：过滤噪音数据

在配置告警分级之前，先清理数据源。常见的噪音来源包括：
浏览器扩展或第三方广告/分析脚本产生的错误与您的业务无关，建议排除：
  • 错误堆栈 包含 chrome-extension://
  • 错误堆栈 包含 moz-extension://
  • 错误堆栈 包含 cdn.third-party.com
某些错误频繁出现但不影响用户体验：
  • 错误消息 包含 ResizeObserver loop
  • 错误消息 包含 Script error
如果您只关注生产环境的告警，可以过滤其他环境的错误：
  • 环境 不包含 production
被过滤的 Error 不会参与 Issue 聚合和告警，但数据仍然保留，您可以在查看器中通过筛选条件查看这些被过滤的错误。

​
第二步：配置告警分级

过滤噪音后，通过告警分级规则区分不同错误的重要程度。

​
分级策略建议

​
推荐规则配置

以下是按业务优先级从高到低排列的推荐规则：
1

生产环境崩溃 → P0

崩溃意味着应用完全不可用，需要最高优先级响应。
  • 条件：环境 包含 production，且 是否崩溃 包含 true
  • 告警级别：P0
2

VIP 用户错误 → P0

VIP 用户的体验直接关系到商业价值。
  • 条件：用户 ID 包含 vip（或通过自定义字段 context.user.level 包含 vip 来匹配）
  • 告警级别：P0
3

核心页面错误 → P1

支付、登录、结算等核心业务页面的错误需要优先处理。
  • 条件：页面 URL 包含 /payment
  • 告警级别：P1
可以为每个核心页面创建单独的规则，或在同一规则中使用多个匹配值。
4

其他错误 → P2（默认）

未匹配任何规则的错误自动归为 P2，按常规流程处理。无需额外配置。
规则数量建议控制在 3-6 条，覆盖最关键的场景即可。过多的规则会增加维护成本，且容易导致优先级混乱。

​
第三步：在 Flashduty 中精细化处理

RUM 侧的告警分级基于单个 Error 的属性，如需基于 Issue 的整体影响做进一步处理，可以在 Flashduty 的告警处理 Pipeline 中配置。

​
典型场景方案

电商应用的核心是交易流程，告警配置应围绕支付和下单环节展开。

​
常见问题

两者互补，适用于不同维度的判断：
  • RUM 告警分级：基于单个 Error 的属性（用户、页面、环境等），适合在源头快速判定
  • Flashduty Pipeline：基于 Issue 的整体信息（影响用户数、错误数量等），适合做更全面的评估
建议在 RUM 侧设定基础优先级，在 Flashduty 侧做补充调整。
不会。如果不配置任何过滤规则和告警分级，所有 Error 仍然会聚合为 Issue 并以默认严重程度投递到 Flashduty。现有行为完全保持不变。

​
延伸阅读

Issue 告警

告警触发条件、自定义分级和数据过滤的完整配置说明

告警处理 Pipeline

在集成层对告警进行清洗、转换和过滤

告警降噪

在协作空间层面聚合和抑制告警

告警分派

配置分派策略，将告警路由到正确的值班人员