文档

告警分组合并

更新时间:

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

路由合并规则

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

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

参考

合并基准

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

合并基本类型

说明

内置合并基准

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

  • 按告警源规则+所有标签:由相同告警规则触发的告警,且其标签相同时,合并为一组进行告警通知。

  • 按告警源规则:由相同告警规则触发的告警合并为一组,进行告警通知。

  • 按告警源项目:属于同一Project下的告警合并为一组,进行告警通知。

  • 按告警源项目+严重度:属于同一Project下的告警,且其严重度相同时,合并为一组进行告警通知。

  • 按告警源项目+所有标签:属于同一Project下的告警,且其标签相同时,合并为一组进行告警通知。

自定义合并基准

您使用告警属性和告警标签自定义合并基准。

  • 可作为合并基准的告警属性包括用户aliuid、告警规则ID、告警显示名称、告警严重度、规则所在区域和规则所在项目。

  • 可作为合并基准的告警标签包括不使用标签、使用所有标签和自定义标签。

行动策略

行动策略定义了告警通知的发送方式。您可以在设置告警路由合并策略时或创建告警规则时关联相应的行动策略。如果在合并策略配置中选择了动态行动策略,则优先采用告警规则创建时指定的行动策略。若选择了其他行动策略,则按照合并策略中指定的行动策略。

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

  • 场景1:在首次等待时间内只产生告警A。

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

    image
    • 在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。

    image
    • 在00:00:00~00:00:05期间,告警A和告警B产生,同时告警合并集合被创建,但是由于设置了首次等待时间,所以日志服务不会立即发送通知。

    • 在00:00:05(达到首次等待时间)时,第一次发送告警通知。

    • 第一次发送告警通知后,以变化等待时间为周期,对合并集合内的告警进行检查。在00:00:05~04:01:05期间,该合并集合内一直只有告警A和告警B。直到距离上次发送告警的间隔达到重复等待时间(4小时),即在04:01:05时,第二次发送告警通知。

参数

说明

首次等待

首次创建合并集合后,等待多久发送第一次告警通知。通常设置为秒级别的时间。

变化等待

合并集合内的告警数据(新增告警或告警状态改变)发生变化后,等待多久发送告警通知。通常设置为分钟级别的时间。如果您需要尽快收到告警通知,也可设置为秒级时间。

重复等待时间

合并集合内的告警数据重复(无新增告警和状态变化,仅其他属性例如标题、内容等改变)后,等待多久发送告警通知。通常设置为小时级别的时间。

说明

当您在创建时配置了动态行动策略,则无需在告警策略中配置重复等待时间。系统默认用告警监控规则的重复等待时间覆盖告警分组的重复等待时间。

示例

创建告警监控规则时,您可以配置不同的告警策略,将触发的告警进行分组合并或者不合并操作。以下是具体示例。

场景1:分组合并

按照规则所在项目、env标签和service标签,对告警进行合并。

  • 告警事件

    // 告警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"
      }
    }
  • 配置

    image

  • 合并结果

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

场景2:不合并机制

在告警策略的路由合并配置中,如果设置合并基准告警规则+所有标签,则告警会按照合并基准分到不同合并集合。例如,有如下两个告警监控规则:

  • 告警监控规则1开启分组评估,告警策略配置为不打开高级模式开关,合并基准告警规则+所有标签。那么告警管理将分别发送主机1告警、主机2告警和主机3告警通知。

  • 告警监控规则2不开启分组评估,告警策略配置为不打开高级模式开关,合并基准告警规则+所有标签。那么告警管理将发送一条包含所有主机的告警通知。

buhebing