告警静音规则的工作原理 - Amazon CloudWatch

告警静音规则的工作原理

以下场景说明了告警静音规则如何影响目标警报,以及告警操作是如何被静音或执行的。

注意
  • 将告警静音会使与所有告警状态相关的操作静音,包括 OK、ALARM 和 INSUFFICIENT_DATA。下图所示的行为适用于与所有告警状态相关的操作。

  • 当您将 Metrics Insights 告警静音时,该告警的所有贡献者指标系列也会自动被静音。

场景:当静音规则处于活动状态时,告警操作被静音

考虑到

  • 告警已针对其 ALARM 状态配置了操作

  • 告警静音规则计划在 t1 到 t5 之间处于活动状态,以告警为目标

  • t0 时:告警处于 OK 状态,静音规则状态为 SCHEDULED

  • t1 时:静音规则状态变为 ACTIVE

  • t2 时:告警转换到 ALARM 状态,操作被静音,因为告警已被静音规则有效静音。

  • t4 时:当静音规则仍处于活动状态时,告警恢复到 OK 状态

  • t5 时:静音规则变为非活动状态,但由于告警现在处于 OK 状态,因此不会执行任何 ALARM 操作

场景:静音规则处于活动状态时告警动作被静音,并在静音窗口后被重新触发

考虑到

  • 告警已针对其 ALARM 状态配置了操作

  • 告警静音规则计划在 t1 到 t5 之间处于活动状态,以告警为目标

  • t0 时:告警处于 OK 状态,静音规则状态为 SCHEDULED

  • t1 时:静音规则状态变为 ACTIVE

  • t2 时:告警转换到 ALARM 状态,操作被静音,因为告警已被静音规则有效静音。

  • t4 时:静音窗口变为非活动状态,告警仍处于 ALARM 状态

  • t5 时:执行告警动作,因为静音窗口已结束,且告警仍处于最初被静音时的状态(ALARM)

场景:多个重叠的告警静音规则

考虑到

  • 告警已针对其 ALARM 状态配置了操作

考虑到有两条静音规则,

  • 告警静音规则 1:将从 t1 到 t5 的告警静音

  • 告警静音规则 2:将从 t3 到 t9 的告警静音

  • t0 时,告警处于 OK 状态,两个静音规则均处于 SCHEDULED 状态

  • t1 时:第一条静音规则变为 ACTIVE

  • t2 时:告警转变为 ALARM 状态,操作被静音

  • t3 时:第二条静音规则变为 ACTIVE

  • t5 时:第一条静音规则变为非活动状态,但告警操作仍处于静音状态,因为第二条静音规则仍处于活动状态

  • t8 时:执行告警动作,因为第二个静音窗口已结束,且告警仍处于最初被静音时的状态(ALARM)

场景:当静音规则更新结束静音窗口时,将执行静音告警操作

考虑到

  • 告警已针对其 ALARM 状态配置了操作

  • 告警静音规则计划在 t1 到 t8 之间处于活动状态,以告警为目标

  • t0 时:告警处于 OK 状态,静音规则为 SCHEDULED 状态

  • t1 时:静音规则变为 ACTIVE

  • t2 时:告警转变为 ALARM 状态,操作被静音

  • t6 时:静音规则配置被更新,使得时间窗口在 t6 时结束。由于静音规则不再处于活动状态,告警操作将在 t6 时立即执行。

注意

同样的行为也适用,

  • 如果在 t6 时删除了静音规则。删除静音规则将会立即取消告警的静音。

  • 如果告警从静音规则目标(在 t6 时)中被移除,则告警将立即被取消静音。

场景:如果在静音窗口期间更新告警动作,则会执行新操作

考虑到

  • 告警已针对其 ALARM 状态配置了操作

  • 告警静音规则计划在 t1 到 t8 之间处于活动状态,以告警为目标

  • t0 时:告警处于 OK 状态,静音规则为 SCHEDULED 状态。SNS 操作在告警处于 ALARM 状态下被配置。

  • t1 时:静音规则变为 ACTIVE

  • t2 时:告警转变为 ALARM 状态,配置的 SNS 操作被静音

  • t6 时:告警配置被更新,以移除 SNS 操作并添加 Lambda 操作

  • t8 时:执行配置为告警的 lambda 操作,因为静音窗口已结束,且告警仍处于最初被静音时的状态(ALARM)

注意

如果在静音窗口期间(如上述示例中的 t6 时)移除了所有告警动作,则在静音窗口结束时(如上述示例中的 t8 时)将不会执行任何操作