告警管理系统接收到告警后，按照路由合并策略对符合条件的告警进行合并分组，并归到合并集合中。合并集合在经过抑制、静默、去重等操作后，被发送到行动（通知）管理系统中进行告警通知。

路由合并规则

告警路由合并基于合并基准、行动策略、首次等待时间、变化等待时间和重复等待时间完成。只有上述配置完全相同时，才会被归到同一个合并集合中。

例如某服务中的2个主机分别从20:00和20:01开始每分钟触发一次高CPU告警。此时您可以按照服务名称创建告警合并策略，在首次及新增的告警被发送后，后续重复的告警将被延迟发送。

参考

合并基准

合并基准表示根据告警属性和告警标签进行合并。告警提供内置合并基准和自定义合并基准，详细说明如下表所示。
合并基本类型 说明
内置合并基准

日志服务提供内置的合并基准。

  • 按告警源规则+所有标签
  • 按告警源规则
  • 按告警源项目
  • 按告警源项目+严重度
  • 按告警源项目+所有标签
自定义合并基准
您使用告警属性和告警标签自定义合并基准。
  • 可作为合并基准的告警属性包括用户aliuid、告警规则ID、告警显示名称、告警严重度、规则所在区域和规则所在项目。
  • 可作为合并基准的告警标签包括不使用标签、使用所有标签和自定义标签。
例如按照规则所在项目、env标签和service标签，对告警进行合并。配置示例如下：
  • 配置示例自定义合并基准
    • 配置合并基准为自定义。
    • 配置告警属性为规则所在项目。
    • 配置告警标签为自定义。
    • 配置自定义标签为env,service。
    • 配置行动策略为SLS内置行动策略。
    • 配置首次等待为30秒。
  • 告警事件
    // 告警A
{
  "alert_name": "Alert1",
  "project": "Project1",
  "labels": {
    "env": "test",
    "service": "service1"
  }
}

// 告警B
{
  "alert_name": "Alert2",
  "project": "Project1",
  "labels": {
    "env": "prod",
    "service": "service2"
  }
}

// 告警C
{
  "alert_name": "Alert3",
  "project": "Project1",
  "labels": {
    "env": "test",
    "service": "service1"
  }
}

// 告警D
{
  "alert_name": "Alert4",
  "project": "Project1",
  "labels": {
    "env": "prod",
    "service": "service2"
  }
}
  • 合并结果

    告警A和告警C归到同一个合并集合中，告警B和告警D被归到同一个合并集合中。

行动策略

行动策略用于定义告警通知的发送方式。您可以在行动策略管理页面，配置和查看行动策略。具体操作，请参见创建行动策略。

日志服务还提供动态行动策略。如果您在配置路由合并策略时，配置行动策略为动态行动策略，则表示通过告警监控规则来指定行动策略。更多信息，请参见动态行动策略机制。

首次等待、变化等待和重复等待

告警合并后，行动（通知）管理系统将统一发送告警通知。但由于合并集合内的告警并不是同时产生的，因此日志服务提供了首次等待时间（group_wait）、变化等待时间（group_interval）和重复等待时间（repeat_interval）来控制告警通知的发送频率。这三个时间可用于避免告警风暴，也可在一定程度上保证告警通知的时效性。具体说明如下：
参数 说明
首次等待 首次创建合并集合后，等待多久发送第一次告警通知。通常设置为秒级别的时间，便于告警合并后再发送，避免告警风暴。
变化等待 合并集合内的告警数据发生变化后，等待多久发送告警通知。通常设置为分钟级别的时间。如果您需要尽快收到告警通知，也可设置为秒级时间。

此处的变化是指新增告警或告警状态改变。
重复等待时间 合并集合内的告警数据重复后，等待多久发送告警通知。通常设置为小时级别的时间。

此处的重复是指无新增告警和状态变化，仅其他属性（例如标题、内容等）改变。

说明 当您在创建时配置了动态行动策略，则无需在告警策略中配置重复等待时间。系统默认使用告警监控规则中所配置的重复等待时间作为告警分组的重复等待时间。
  • 场景1：在首次等待时间内只产生告警A。
    假设首次等待时间为5秒、变化等待时间为1分钟、重复等待时间为4小时，橙色表示告警A、蓝色代表告警B。举例
    • 在00:00:00时，告警A产生，同时告警合并集合被创建，但是由于设置了首次等待时间，所以日志服务不会立即发送通知。
    • 在00:00:05（达到首次等待时间）时，日志服务第一次发送告警通知。
    • 第一次发送告警通知后，以变化等待时间为周期，对合并集合内的告警进行检查。第一个变化等待时间（1分钟）内，告警B产生并进入合并集合。所以在00:01:05时，日志服务第二次发送告警通知。
    • 继续以变化等待时间为周期进行检查，该合并集合内一直只有告警A和告警B。直到距离上次发送告警的间隔达到重复等待时间（4小时），即在04:01:05时，日志服务第三次发送告警通知。
  • 场景2：在首次等待时间内产生了告警A和告警B。

    假设首次等待时间为5秒、变化等待时间为1分钟、重复等待时间为4小时，橙色表示告警A、蓝色代表告警B。

    合并流程
    • 在00:00:00~00:00:05期间，告警A和告警B产生，同时告警合并集合被创建，但是由于设置了首次等待时间，所以日志服务不会立即发送通知。
    • 在00:00:05（达到首次等待时间）时，第一次发送告警通知。
    • 第一次发送告警通知后，以变化等待时间为周期，对合并集合内的告警进行检查。在00:00:05~04:01:05期间，该合并集合内一直只有告警A和告警B。直到距离上次发送告警的间隔达到重复等待时间（4小时），即在04:01:05时，第二次发送告警通知。