Merge pull request #12 from flashcatcloud/rum/alert

feat: update rum issue alert docs

Author: Fiona2016

zh/rum/best-practices/alert-noise-reduction.mdx

@@ -9,16 +9,23 @@ Flashduty RUM 提供了从数据过滤、告警分级到 Flashduty 告警处理
 
 本文将介绍 RUM 告警配置的核心原则和典型场景方案，帮助您快速减少无效告警干扰。
 
+<Info>
+  本文涉及的过滤和分级配置均在控制台「应用管理」中完成：选择目标应用，点击左侧「告警设置」即可配置。详细配置说明请参考
+  [Issue 告警](/zh/rum/error-tracking/issue-alerts)。
+</Info>
+
+![2026-03-13-15-08-11](https://docs-cdn.flashcat.cloud/imges/png/7fbb901611a71dd559da8d59c6251472.png)
+
 ## 告警处理链路
 
 RUM 告警从 Error 产生到通知到人，经过以下四层处理：
 
-| 层级 | 配置位置 | 核心作用 |
-|------|----------|----------|
-| ① 数据过滤 | RUM 应用 → 告警设置 | 在源头排除不需要的 Error，减少无效 Issue |
-| ② 告警分级 | RUM 应用 → 告警设置 | 根据 Error 属性设定 Issue 优先级 |
-| ③ 告警处理 | Flashduty 集成 → 告警处理 | 基于 Issue 维度做优先级调整、丢弃/抑制 |
-| ④ 告警分派 | Flashduty 协作空间 | 路由到团队、通知值班人员 |
+| 层级       | 配置位置                  | 核心作用                                 |
+| ---------- | ------------------------- | ---------------------------------------- |
+| ① 数据过滤 | RUM 应用 → 告警设置       | 在源头排除不需要的 Error，减少无效 Issue |
+| ② 告警分级 | RUM 应用 → 告警设置       | 根据 Error 属性设定 Issue 优先级         |
+| ③ 告警处理 | Flashduty 集成 → 告警处理 | 基于 Issue 维度做优先级调整、丢弃/抑制   |
+| ④ 告警分派 | Flashduty 协作空间        | 路由到团队、通知值班人员                 |
 
 配置时建议**从上到下依次设置**：先过滤噪音，再分级告警，最后在 Flashduty 侧做精细化处理。
 
@@ -33,22 +40,26 @@ RUM 告警从 Error 产生到通知到人，经过以下四层处理：
     - 错误堆栈 包含 `chrome-extension://`
     - 错误堆栈 包含 `moz-extension://`
     - 错误堆栈 包含 `cdn.third-party.com`
+
   </Accordion>
   <Accordion title="已知无害错误">
     某些错误频繁出现但不影响用户体验：
 
     - 错误消息 包含 `ResizeObserver loop`
     - 错误消息 包含 `Script error`
+
   </Accordion>
   <Accordion title="非核心环境错误">
     如果您只关注生产环境的告警，可以过滤其他环境的错误：
 
     - 环境 不包含 `production`
+
   </Accordion>
 </AccordionGroup>
 
 <Tip>
-被过滤的 Error 不会参与 Issue 聚合和告警，但数据仍然保留，您可以在查看器中通过筛选条件查看这些被过滤的错误。
+  被过滤的 Error 不会参与 Issue
+  聚合和告警，但数据仍然保留，您可以在查看器中通过筛选条件查看这些被过滤的错误。
 </Tip>
 
 ## 第二步：配置告警分级
@@ -57,11 +68,11 @@ RUM 告警从 Error 产生到通知到人，经过以下四层处理：
 
 ### 分级策略建议
 
-| 优先级 | 适用场景 | 期望响应时间 |
-|--------|----------|--------------|
-| **P0（Critical）** | 核心业务中断、VIP 用户受影响、生产环境崩溃 | 立即响应 |
-| **P1（Warning）** | 重要功能异常、核心页面错误 | 当日处理 |
-| **P2（Info）** | 非核心功能错误、低影响问题 | 按计划处理 |
+| 优先级             | 适用场景                                   | 期望响应时间 |
+| ------------------ | ------------------------------------------ | ------------ |
+| **P0（Critical）** | 核心业务中断、VIP 用户受影响、生产环境崩溃 | 立即响应     |
+| **P1（Warning）**  | 重要功能异常、核心页面错误                 | 当日处理     |
+| **P2（Info）**     | 非核心功能错误、低影响问题                 | 按计划处理   |
 
 ### 推荐规则配置
 
@@ -73,12 +84,14 @@ RUM 告警从 Error 产生到通知到人，经过以下四层处理：
 
     - 条件：环境 包含 `production`，且 是否崩溃 包含 `true`
     - 告警级别：P0
+
   </Step>
   <Step title="VIP 用户错误 → P0">
     VIP 用户的体验直接关系到商业价值。
 
     - 条件：用户 ID 包含 `vip`（或通过自定义字段 `context.user.level` 包含 `vip` 来匹配）
     - 告警级别：P0
+
   </Step>
   <Step title="核心页面错误 → P1">
     支付、登录、结算等核心业务页面的错误需要优先处理。
@@ -87,25 +100,27 @@ RUM 告警从 Error 产生到通知到人，经过以下四层处理：
     - 告警级别：P1
 
     可以为每个核心页面创建单独的规则，或在同一规则中使用多个匹配值。
+
   </Step>
   <Step title="其他错误 → P2（默认）">
     未匹配任何规则的错误自动归为 P2，按常规流程处理。无需额外配置。
   </Step>
 </Steps>
 
 <Tip>
-规则数量建议控制在 3-6 条，覆盖最关键的场景即可。过多的规则会增加维护成本，且容易导致优先级混乱。
+  规则数量建议控制在 3-6
+  条，覆盖最关键的场景即可。过多的规则会增加维护成本，且容易导致优先级混乱。
 </Tip>
 
 ## 第三步：在 Flashduty 中精细化处理
 
 RUM 侧的告警分级基于单个 Error 的属性，如需基于 Issue 的整体影响做进一步处理，可以在 Flashduty 的[告警处理 Pipeline](/zh/on-call/integration/alert-integration/alert-pipelines) 中配置。
 
-| 处理场景 | 配置方式 |
-|----------|----------|
-| 抑制重复告警 | 同一 `alert_key` 在 1 小时内只告警一次 |
+| 处理场景       | 配置方式                                                                       |
+| -------------- | ------------------------------------------------------------------------------ |
+| 抑制重复告警   | 同一 `alert_key` 在 1 小时内只告警一次                                         |
 | 自定义告警标题 | 模板示例：`[RUM] [{{Labels.env}}] {{Labels.error_type}} - {{Labels.view_url}}` |
-| 低影响错误降级 | 当 `labels.affected_users` < 5 时，将严重程度更新为 Info |
+| 低影响错误降级 | 当 `labels.affected_users` < 5 时，将严重程度更新为 Info                       |
 
 ## 典型场景方案
 
@@ -119,6 +134,7 @@ RUM 侧的告警分级基于单个 Error 的属性，如需基于 Issue 的整
     | 告警分级 | P0：支付页面错误、崩溃；P1：商品详情页/购物车错误 |
     | 告警处理 | 抑制窗口：30 分钟；标题模板包含页面路径 |
     | 告警分派 | P0 → 短信+电话通知，P1 → IM 通知 |
+
   </Tab>
   <Tab title="SaaS 应用">
     SaaS 应用需要关注不同租户的体验差异。
@@ -129,6 +145,7 @@ RUM 侧的告警分级基于单个 Error 的属性，如需基于 Issue 的整
     | 告警分级 | P0：企业版租户错误（通过 `context.tenant.plan` 匹配）；P1：核心功能页面错误 |
     | 告警处理 | 标题模板包含租户信息；低影响告警降级 |
     | 告警分派 | 按团队分配到不同协作空间 |
+
   </Tab>
   <Tab title="内容型网站">
     内容型网站对可用性要求相对宽松，重点关注加载和渲染问题。
@@ -139,6 +156,7 @@ RUM 侧的告警分级基于单个 Error 的属性，如需基于 Issue 的整
     | 告警分级 | P0：崩溃；P1：首页/搜索页错误 |
     | 告警处理 | 抑制窗口：1 小时；影响用户数 < 10 的告警降级 |
     | 告警分派 | P0 → IM 通知，P1/P2 → 邮件通知 |
+
   </Tab>
 </Tabs>
 
@@ -160,6 +178,7 @@ RUM 侧的告警分级基于单个 Error 的属性，如需基于 Issue 的整
     - **Flashduty Pipeline**：基于 Issue 的整体信息（影响用户数、错误数量等），适合做更全面的评估
 
     建议在 RUM 侧设定基础优先级，在 Flashduty 侧做补充调整。
+
   </Accordion>
   <Accordion title="默认告警行为会改变吗？">
     不会。如果不配置任何过滤规则和告警分级，所有 Error 仍然会聚合为 Issue 并以默认严重程度投递到 Flashduty。现有行为完全保持不变。
@@ -169,16 +188,32 @@ RUM 侧的告警分级基于单个 Error 的属性，如需基于 Issue 的整
 ## 延伸阅读
 
 <CardGroup cols={2}>
-  <Card title="Issue 告警" icon="bell" href="/zh/rum/error-tracking/issue-alerts">
+  <Card
+    title="Issue 告警"
+    icon="bell"
+    href="/zh/rum/error-tracking/issue-alerts"
+  >
     告警触发条件、自定义分级和数据过滤的完整配置说明
   </Card>
-  <Card title="告警处理 Pipeline" icon="filter" href="/zh/on-call/integration/alert-integration/alert-pipelines">
+  <Card
+    title="告警处理 Pipeline"
+    icon="filter"
+    href="/zh/on-call/integration/alert-integration/alert-pipelines"
+  >
     在集成层对告警进行清洗、转换和过滤
   </Card>
-  <Card title="告警降噪" icon="volume-slash" href="/zh/on-call/channel/noise-reduction">
+  <Card
+    title="告警降噪"
+    icon="volume-slash"
+    href="/zh/on-call/channel/noise-reduction"
+  >
     在协作空间层面聚合和抑制告警
   </Card>
-  <Card title="告警分派" icon="route" href="/zh/on-call/channel/escalation-rule">
+  <Card
+    title="告警分派"
+    icon="route"
+    href="/zh/on-call/channel/escalation-rule"
+  >
     配置分派策略，将告警路由到正确的值班人员
   </Card>
 </CardGroup>