了解降噪过程

理解Flashduty如何针对告警进行降噪。

---

当Flashduty接收到告警事件（比如Zabbix的一条告警通知），系统会自动触发一条告警，而这条告警将会触发一条故障。多条相似的活跃告警，可能会被聚合到同一条故障中，一起分派、通知和处理，这可以显著降低通知频次并提高处置效率。

降噪模型

---

基本概念

• 事件（Event）：来自于原始监控系统（比如Zabbix），每一次触发和恢复通知都是一次事件。
• 告警（Alert）：由事件自动触发，原始监控系统中同一条告警在不同时刻发生的事件，将被Flashduty合入到同一条告警中。
• 故障（Incident）：Flashduty平台处理的主要对象，一般由告警自动触发，也可以手动创建。故障可以理解为相似告警的组合，Flashduty依据用户配置的聚合策略，将相似的告警自动聚合到一起进行分派和处理。

降噪过程

故障有两种触发方式：手工创建和自动触发。告警降噪仅在自动触发这个场景下生效，一般降噪过程如下：

1. 监控系统产生告警，推送到Flashduty
2. Flashduty判断新事件是否可以合入某个活跃告警，如果没有则触发一条新的告警，否则并入
3. Flashduty判断新告警是否可以合入某个活跃故障，如果没有则触发一条新的故障，否则并入
4. Flashduty依据分派策略进行人员分派，并通知
5. 人员收到通知，开始处理故障

设置告警聚合

---

前往【协作空间详情】-【告警降噪】，可以设置 告警聚合 策略。当创建一个新的协作空间，默认关闭告警聚合，建议您手动开启并按需设置聚合策略。

通用配置

• 聚合窗口： 您可以选择仅聚合临近发生的告警（有更强的相关性），超出时间窗口的告警将触发新的故障。注意该窗口为滑动窗口，总是随着新告警合入而延长。
• 风暴预警： 故障触发后，系统将立即分派并通知（假设您没有设置延迟通知），随后持续合入新的告警，但不会触发新的通知，这会导致您无法及时感知到告警风暴。因此我们提供此阈值，当合入告警数量达到阈值，系统将触发风暴预警，提醒您加急处理。
• 严格聚合： 开启状态时，告警与故障中值都为空的聚合条件将视为不同项；关闭状态时，告警与故障中值都为空的聚合条件将视为相同项（智能聚合不支持）。
• 预览：您可使用预览功能，拉取最近发生的事件，并实时渲染降噪结果，以此评估降噪效果。

聚合模式

Flashduty 提供了两种聚合模式，分别是 智能聚合 和 规则聚合，智能聚合利用机器学习算法，能够深入分析故障信息的语义内容，识别并合并相似度高的事件。这种方式可以省去您手动配置聚合规则的麻烦，适用于对聚合要求较为宽松的场景。相比之下，规则聚合提供了一种更为直接和定制化的途径，允许用户根据自身的业务逻辑和需求配置特定的聚合规则。用户可以定义哪些条件下的事件应该被归类在一起，从而确保事件管理符合组织的具体要求。这种方法为用户提供完全的控制权，使得复杂的事件流可以根据预设的标准进行有效的管理和优先级排序。

智能聚合

• 智能聚合： 当新触发告警与活跃故障的内容高度相似时，将告警合入故障。

规则聚合

• 统一控制： 空间下所有新告警使用相同维度进行聚合，支持选择多个属性和标签，仅当所有属性和标签完全相同时，该组条件匹配。

• 细粒度控制： 新告警按条件匹配聚合维度，未匹配到则使用默认维度进行聚合，如未设置默认维度，则不聚合。

查看聚合示例

---

设置空间按照 告警检查项 进行聚合，系统依次收到5次告警通知，这些通知依次触发了告警和故障：

故障：cpu idle < 20% / es.nj.03，Critical

  - 告警cpu idle < 20% / es.nj.03：
      - 事件1：es.nj.03，cpu.idle = 10%，Critical
      - 事件2：es.nj.03，cpu.idle = 18%，Warning
      - 事件4：es.nj.03，cpu.idle = 10%，Ok

  - 告警cpu idle < 20% / es.nj.01：
      - 事件3：es.nj.01，cpu.idle = 15%，Warning
  
  - 告警cpu idle < 20% / es.nj.02：
      - 事件5：es.nj.02，cpu.idle = 19%，Warning

我们通过控制台故障详情页，可以看到最终的【故障-告警-事件】关联关系：

• 点击告警标题，您可以查看关联告警的详情，包括告警的时间线和关联事件
• 点击事件点，您可以查看事件上报的具体内容，包括标签和描述

常见问题

---

故障的标题是否会随告警合入改变？

不会，默认故障的标题与触发该故障的第一条告警完全相同，您可以在任何时候手动修改故障标题，此标题不会随新告警合入发生变化。

故障的标签是否会随告警合入改变？

• 手工创建的告警：不会，其标签列表将永远为空
• 自动触发的告警：有可能，此时故障的标签将与触发该故障的第一条告警的标签保持一致，如果告警的标签发生变化，那么故障的标签也会同步变化。

告警的标签是否会随事件合入改变？

会的，告警的标签总是与新合入的事件保持一致。比如，如果您10点钟收到一条告警”CPU idle 偏低“，触发值为10%，随着告警合入更多事件，该触发值标签可能会动态变化。但如果新收到的事件，是一条恢复事件，告警将保持已存在的标签不变，并增加之前不存在的标签。我们的原则是，告警展示的标签尽可能保持触发时的样子。

故障合入的告警数量是否存在上限？

存在，我们设置了单个故障最多聚合1000条告警，这主要是为了降低控制台页面的渲染时间。但同时，Flashduty是一个高性能的事件处理系统，后台存在大量并发逻辑，因此当您看到故障聚合超过1000条告警时，这是可能出现的正常现象。

告警合入的事件数量是否存在上限？

不存在。但一个告警聚合事件的窗口最大为24小时。这意味着，如果一个告警触发24小时后还没有恢复，未来也不会合入新的事件。如果Flashduty收到新的事件，会产生新的告警。

为什么我推送的事件数量和告警关联的事件数量对不上？

事件到告警的合并也是一个降噪过程。如果Flashduty认为新上报的事件和告警变化不大（比如状态、严重程度、描述等都没有变化），Flashduty会直接丢弃新上报的事件，并使用新事件的标签来覆盖已有的标签。