RUM 告警太多？从这里开始配置
凌晨两点，手机一阵震动——又是一条 RUM 告警。打开一看：ResizeObserver loop limit exceeded，某个浏览器插件搞的鬼，和你的业务毫无关系。
这种场景熟悉吗？告警轰炸让人疲惫，真正重要的问题反而淹没在噪音里。
好消息是，这个问题完全可以系统地解决。Flashduty RUM 提供了从数据过滤、告警分级到告警处理的完整链路，按顺序配置好这三层，噪音可以减少 80% 以上。
告警是怎么一路"走"到你手机上的？
先搞清楚链路，再决定在哪里拦截。
| 层级 | 在哪里配 | 干什么 |
|---|---|---|
| ① 数据过滤 | RUM 应用 → 告警设置 | 在源头拦截不需要的 Error，让它们根本不进入 Issue |
| ② 告警分级 | RUM 应用 → 告警设置 | 给通过的 Error 打上优先级标签（P0/P1/P2） |
| ③ 告警处理 | Flashduty 集成 → 告警处理 | 基于 Issue 整体情况再做一轮优先级调整、合并或丢弃 |
| ④ 告警分派 | Flashduty 协作空间 | 根据优先级路由到对应团队和值班人 |
关键原则：从上到下配置。 先把源头的垃圾过滤干净，后面的处理才能更精准。
第一步：把"垃圾"挡在门外
治理告警噪音，最有效的方式是从源头过滤，让不必要的 Error 直接不进入 Issue 聚合。
以下三类错误是最常见的噪音制造者：
浏览器扩展 & 第三方脚本的错误
这些错误和你的代码没有任何关系，但它们会混进来占用告警配额：
- 错误堆栈 包含
chrome-extension:// - 错误堆栈 包含
moz-extension:// - 错误堆栈 包含
cdn.third-party.com
反复出现的"无害"错误
有些错误天天报，但从没影响过一个用户：
- 错误消息 包含
ResizeObserver loop（浏览器渲染副作用，无需处理） - 错误消息 包含
Script error（跨域脚本的通用报错，无实质信息）
非生产环境的错误
测试、预发环境的错误在开发期间有意义，但不应该在凌晨把值班同学吵醒：
- 环境 不包含
production
放心：过滤 ≠ 删除。 被过滤的 Error 数据仍然完整保留，随时可以在查看器中调出来看，只是不会触发 Issue 聚合和告警通知。
第二步：给剩下的错误定"优先级"
噪音过滤完之后，剩下的错误才是真正值得关注的。接下来要做的，是区分它们的轻重缓急。
三级优先级参考
| 优先级 | 什么情况用 | 期望响应时间 |
|---|---|---|
| P0（Critical） | 核心业务中断、VIP 用户受影响、生产环境崩溃 | 立刻处理，不过夜 |
| P1（Warning） | 重要功能异常、核心页面错误 | 当日内处理 |
| P2（Info） | 非核心功能错误、影响范围小的问题 | 排期处理 |
推荐的四条规则
按优先级从高到低依次配置，未匹配的兜底走 P2：
1. 生产环境崩溃 → P0
崩溃（crash）= 应用完全挂掉，优先级毫无争议。
- 条件：环境 包含
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 里做最后一道精细化处理
前两步是基于"单个 Error 的属性"来判断，但有些场景需要看 Issue 的整体情况才能决定——比如"这个错误虽然是 P1，但只影响了 2 个用户，要不要降级？"
这类判断放在 Flashduty 告警处理 Pipeline 里做更合适：
| 处理场景 | 配置方式 |
|---|---|
| 抑制重复告警 | 同一 alert_key 在 1 小时内只触发一次通知 |
| 自定义告警标题 | 模板示例：[RUM] [{{Labels.env}}] {{Labels.error_type}} - {{Labels.view_url}} |
| 低影响错误自动降级 | 当 labels.affected_users < 5 时，将严重程度调整为 Info |
不同应用类型怎么配？
电商应用
电商的命脉是交易流程，配置重心放在支付和下单环节。
| 层级 | 配置建议 |
|---|---|
| 数据过滤 | 排除第三方广告脚本、ResizeObserver loop |
| 告警分级 | P0：支付页面错误、崩溃；P1：商品详情页 / 购物车错误 |
| 告警处理 | 抑制窗口 30 分钟；标题模板包含页面路径 |
| 告警分派 | P0 → 短信 + 电话；P1 → IM |
SaaS 应用
SaaS 要特别关注不同租户的体验差异，大客户的报错不能和普通用户混在一起。
| 层级 | 配置建议 |
|---|---|
| 数据过滤 | 排除浏览器扩展错误、非生产环境 |
| 告警分级 | P0：企业版租户错误（通过 context.tenant.plan 匹配）；P1：核心功能页面 |
| 告警处理 | 标题模板带租户信息；低影响告警自动降级 |
| 告警分派 | 按产品线 / 团队分配到不同协作空间 |
内容型网站
内容站的用户容忍度相对高，重点关注崩溃和核心页面的渲染问题。
| 层级 | 配置建议 |
|---|---|
| 数据过滤 | 排除第三方脚本错误、Script error |
| 告警分级 | P0：崩溃；P1：首页 / 搜索页错误 |
| 告警处理 | 抑制窗口 1 小时；影响用户数 < 10 自动降级 |
| 告警分派 | P0 → IM；P1/P2 → 邮件 |
常见疑问
数据过滤和 Flashduty 告警丢弃，到底有什么区别？
| 对比维度 | RUM 数据过滤 | Flashduty 告警丢弃 |
|---|---|---|
| 发生时机 | Error 聚合为 Issue 之前 | Issue 已创建、投递为告警之后 |
| 数据留存 | Error 数据保留，可在查看器查看 | Issue 数据保留 |
| 影响范围 | 不参与 Issue 聚合，也不产生告警 | Issue 存在，但不发出通知 |
| 适用场景 | 长期稳定的噪音（如第三方脚本错误） | 临时或灵活的告警控制 |
RUM 分级规则和 Flashduty Pipeline 要怎么分工？
简单来说：RUM 侧管"这个错误本身"，Flashduty 侧管"这个 Issue 整体"。
- RUM 告警分级：基于单条 Error 的属性（用户身份、页面 URL、环境等），快速打标
- Flashduty Pipeline：基于 Issue 聚合后的整体数据（影响用户数、错误总量等），做精细调整
建议先在 RUM 侧设好基础优先级，再用 Flashduty 做补充修正。
我什么都不配，会怎样？
一切正常。默认情况下，所有 Error 照常聚合为 Issue，以默认严重程度投递到 Flashduty。这两步配置完全是可选的增强，不影响现有行为。
关于 Flashduty
Flashduty 是一站式可观测性平台，覆盖 RUM 用户体验监控、On-Call 告警管理和 Monitors 统一监控。
RUM（Real User Monitoring） 是本文的主角：通过在页面植入轻量 SDK，自动采集真实用户的页面性能、JS 错误、网络请求、会话行为等数据。不是模拟测试，而是每一个真实用户在真实网络、真实设备上的实际体验。出了问题，可以回放用户操作路径复现现场，也可以关联后端 Trace 做全链路分析。
On-Call 告警管理 是 RUM 告警的"最后一公里"：把来自 RUM、Prometheus、Zabbix、云监控等各路告警统一汇聚，自动降噪聚合，再按值班表派给对的人——支持飞书、钉钉、企业微信、Slack、电话、短信等多种触达方式。目标很简单：让每一条真正重要的告警，在正确的时间找到正确的人，而不是在深夜轰炸整个团队。
延伸阅读
- Issue 告警配置：告警触发条件、自定义分级和数据过滤的完整说明
- 告警处理 Pipeline：在集成层对告警进行清洗、转换和过滤
- 告警降噪：在协作空间层面聚合和抑制告警
- 告警分派：配置分派策略，将告警路由到正确的值班人员
