基于指标的提醒政策的行为

本文档介绍了校准时间段和时长设置如何确定条件的触发时间、提醒政策如何组合多个条件,以及提醒政策如何替换缺失的数据点。此外,还介绍了政策的未结突发事件数量上限、每个突发事件的通知数量,以及导致通知延迟的原因。

此内容不适用于基于日志的提醒政策。如需了解基于日志的提醒政策,请参阅监控日志

校准时间段和时长设置

校准时间段和考量时长是在指定提醒政策的条件时设置的两个字段。本部分简要说明这些字段的含义。

校准时间段

提醒政策中的条件会将校准值与阈值进行比较。校准时间段是一个从特定时间点开始的回溯期;校准器是将点与回溯期合并为一个对齐值的函数。例如,如果校准时间段为五分钟,则在下午 1:00,校准时间段会包含中午 12:55 到下午 1:00 之间接收到的样本。在下午 1:01,校准时间段滑动一分钟,并包含在中午 12:56 到下午 1:01 之间收到的样本。

控制台

您可以使用新建窗口对话框中的滚动窗口滚动窗口函数菜单配置对齐字段。

API

您可以通过在 MetricThresholdMetricAbsence 结构中设置 aggregations.alignmentPeriodaggregations.perSeriesAligner 字段来配置对齐字段。

为了说明校准时间段对提醒政策中的条件的影响,请考虑使用以下条件:使用采样时间段一分钟监控指标。假设将校准时间段设置为 5 分钟,并且将校准器设置为 sum。如果时序的校准值大于 2 且至少三分钟,则该条件被描述为 metactive。在此示例中,假设每分钟评估一次条件。

下图说明条件的多次顺序评估:

说明校准时间段的影响的图表。

图中的每一行都说明条件的单次评估。系统会显示时间序列数据。校准时间段中的点显示为蓝点,所有旧点都是黑色。每一行都会显示校准后的值,以及该值是否大于阈值 2。对于标记为 start 的行,对齐的值的计算结果为 1,小于阈值。下次评估时,校准时间段内的样本总和为 2。在第三次评估中,总和为 3,大于阈值。条件评估器还会启动考量时长计时器。

考量时长

可以使用“时长”或“时长”来防止因单个测量结果而满足的条件。例如,如果指标阈值条件的持续时间为 5 分钟,则只有在 5 分钟间隔内的每次校准测量结果都超过阈值时,系统才会满足条件。如果政策有一个条件,则系统会打开事件,并在满足条件时发送通知。

控制台

您可以使用配置触发器步骤中的重新测试窗口字段来配置时长窗口。

API

您可以通过在 MetricThresholdMetricAbsence 结构中设置 duration 字段来配置时长窗口。

上图说明条件的三次评估。在 start + 2 minutes 时,校准值大于阈值;但不符合条件,因为时长窗口设置为 3 分钟。下图展示了条件下次评估的结果:

说明考量时长的影响的图表。

即使校准后的值大于 start + 2 minutes 处的阈值,在校准后的值大于阈值 3 分钟之前,系统不会满足条件。该操作发生在 start + 5 minutes 时间。

为清楚起见,前面的示例省略了将多个时间序列的校准数据点合并为单一测量结果的可能性。系统会将测量结果与阈值进行比较,以确定是否满足条件。

每当条件不满足条件时,条件都会重置其考量时长。 以下示例说明了此行为:

示例:此提醒政策包含一个指定 5 分钟时长的条件。

如果 HTTP 响应延迟时间超过 2 秒,
并且延迟时间超过阈值 5 分钟,
请创建一个突发事件,并向支持团队发送电子邮件。

以下内容说明了考量时长如何影响条件的评估:

  1. HTTP 延迟时间少于 2 秒。
  2. 在接下来的连续三分钟中,HTTP 延迟时间超过两秒。
  3. 在下一次测量中,延迟时间不到两秒,因此条件会重置时长窗口。
  4. 在接下来的连续五分钟中,HTTP 延迟时间超过两秒,因此满足条件。

    由于政策有一个条件,因此满足条件时会打开突发事件并发送通知。

将考量时长设置为足够长的时间,以便最大限度地减少假正例,但也应足够短,以便确保及时打开突发事件。

选择校准时间段和时长窗口

提醒政策条件按固定频率进行评估。您对校准时间段和考量时长的选择不会决定条件的评估频率。

上图说明了校准时间段决定了校准器合并的数据样本数量。如需合并多个样本,请选择较长的时间段。如需将间隔限制为仅一个样本,请选择较短的时间段。相反,时长窗口会指定校准值必须大于阈值多长时间才能满足条件。若要在单个对齐值大于阈值时满足条件,请将时长窗口设置为 0。

具有多个条件的政策

提醒政策最多可包含 6 个条件。

如果您使用的是 Cloud Monitoring API 或提醒政策具有多个条件,则必须指定突发事件的打开时间。如需配置多个条件的合并方式,请执行以下操作之一:

Google Cloud Console

您可以在多条件触发器步骤中配置组合器选项。

API

您可以使用 AlertPolicy 结构的 combiner 字段配置组合器选项。

下表列出了控制台中的设置、Cloud Monitoring API 中的等效值以及每项设置的说明:

控制台
政策触发器值
Cloud Monitoring API
combiner 值
含义
满足任意条件 OR 如果任何资源导致满足任何条件,则系统会创建一个突发事件。
满足所有条件
,即便每个条件对应不同的
资源

(默认)
AND 如果满足每个条件,则即使存在其他资源导致满足这些条件,也会引发事件。
满足所有条件 AND_WITH_MATCHING_RESOURCE 如果同一个资源导致满足每个条件,则系统会创建一个突发事件。此设置是最严格的组合选择。

在这种情况下,术语“满足”是指条件的配置求得的值为“true”。例如,如果配置为 Any time series is greater than 10 for 5 minutes,那么当此语句的计算结果为 true 时,即满足条件。

示例

以包含两个虚拟机实例 vm1 和 vm2 的 Google Cloud 项目为例。此外,假设您创建了一个提醒政策,其中包含两个条件:

  • 名为 CPU usage is too high 的条件用于监控实例的 CPU 使用率。如果任何实例的 CPU 使用率超过 100 毫秒/秒(1 分钟),即满足此条件。
  • 名为 Excessive utilization 的条件用于监控实例的 CPU 利用率。如果任何实例的 CPU 利用率超过 60% 且持续 1 分钟,就会满足此条件。

最初,假设两个条件的计算结果均为 false

接下来,假设 vm1 的 CPU 使用率超过 100ms/s,持续 1 分钟。由于 CPU 使用率超过一分钟阈值,因此满足条件 CPU usage is too high。如果条件与满足任意条件合并,则会创建突发事件,因为满足条件。如果条件与满足所有条件满足所有条件,即便每个条件对应不同的资源相结合,则系统不会创建突发事件。这些组合器选择要求同时满足这两个条件。

接下来,假设 vm1 的 CPU 使用率超过 100 毫秒/秒,并且 vm2 的 CPU 利用率超过 60% 且持续 1 分钟。这样便可同时满足这两个条件。以下内容描述了条件组合的方式:

  • 满足任意条件:当资源导致条件得到满足时,系统就会创建突发事件。在此示例中,vm2 会导致条件 Excessive utilization 得到满足。

    如果 vm2 导致满足 CPU usage is too high 条件,也会引发事件。创建突发事件是因为导致满足条件 CPU usage is too high 的 vm1 和 vm2 是不同的事件。

  • 满足所有条件,即便每个条件对应不同的资源:由于两个条件都得到满足,因此系统会建立突发事件。

  • 满足所有条件:系统不会创建突发事件,因为此组合器要求同一资源必须导致所有条件都得到满足。在此示例中,系统不会创建任何突发事件,因为 vm1 会导致 CPU usage is too high 得到满足,而 vm2 会导致 Excessive utilization 得到满足。

部分指标数据

当时间序列数据到达或数据延迟时,Monitoring 会将其归类为缺失的数据;缺少数据可能会导致政策不发出提醒,且突发事件不会关闭。来自第三方云提供商的数据延迟可能长达 30 分钟,其中 5-15 分钟的延迟最为常见。延迟时间过长(比指定的考量时长还要长),可能会导致条件进入“未知”状态。当数据最终到达时,Monitoring 可能已丢失条件的一些近期历史记录。由于一旦数据到达,就再也没有证据表明出现过延迟,因此事后对时间序列数据进行检查可能不会揭示这个问题。

控制台

您可以配置 Monitoring 在数据停止到达时如何评估指标阈值条件。例如,当突发事件尚未解决且预期测量结果未到达时,您希望 Monitoring 让突发事件保持打开状态,还是立即将其关闭?同样,如果数据不再到达并且未发生任何突发事件,您是否希望开启突发事件?最后,在数据停止到达后,突发事件应该在多长时间内保持开启状态?

有两个可配置字段,用于指定 Monitoring 在数据停止到达时如何评估指标阈值条件:

  • 如需配置 Monitoring 如何确定缺失数据的替换值,请使用您在条件触发器步骤中设置的评估缺失数据字段。当重新测试期设置为不重新测试时,此字段会被停用。

  • 如需配置 Monitoring 在数据停止到达后关闭未结突发事件之前需要等待的时间,请使用突发事件自动关闭时长字段。您可以在通知步骤中设置自动关闭时长。默认的自动关闭时长为 7 天。

下面介绍了缺失数据字段的不同选项:

控制台
“评估数据缺失”字段
总结 详情
缺少数据 未结突发事件保持未解决状态。
系统不会打开新的突发事件。

对于满足条件,当数据不再到达时,该条件会继续得到满足。如果某项突发事件因该条件而未结清,则该突发事件会保持未解决状态。当突发事件处于未结状态,且未收到任何数据时,自动关闭计时器会在延迟至少 15 分钟后启动。如果计时器超时,突发事件将被关闭。

对于不符合的条件,当数据不再到达时,不再继续满足该条件。

数据点缺失被视为违反政策条件的值 未结突发事件保持未解决状态。
您可以创建新的突发事件。

对于满足条件,当数据不再到达时,该条件会继续得到满足。如果某项突发事件因该条件而未结清,则该突发事件会保持未解决状态。如果突发事件处于未结状态,并且自动关闭时长为 24 小时,但未收到任何数据,则该突发事件会被关闭。

对于不符合的条件,此设置会使指标阈值条件的行为类似于 metric-absence condition。如果数据在重新测试窗口指定的时间内没有到达,则评估此条件是否满足条件。对于具有一个条件的提醒政策,满足该条件会导致打开突发事件。

缺少数据点,不被视为违反政策条件的值 未结突发事件已关闭。
系统不会打开新的突发事件。

对于满足的条件,当数据不再到达时,条件不再满足。如果某项突发事件因该条件而未结清,则该突发事件会被关闭。

对于不符合的条件,当数据不再到达时,不再继续满足该条件。

API

您可以配置 Monitoring 在数据停止到达时如何评估指标阈值条件。例如,当突发事件尚未解决且预期测量结果未到达时,您希望 Monitoring 让突发事件保持打开状态,还是立即将其关闭?同样,如果数据不再到达并且未发生任何突发事件,您是否希望开启突发事件?最后,在数据停止到达后,突发事件应该在多长时间内保持开启状态?

有两个可配置字段,用于指定 Monitoring 在数据停止到达时如何评估指标阈值条件:

  • 如需配置 Monitoring 如何确定缺失数据的替换值,请使用 MetricThreshold 结构的 evaluationMissingData 字段。当 duration 字段为零时,此字段会被忽略。

  • 如需配置 Monitoring 在数据停止到达后关闭未结突发事件之前需要等待的时间,请使用 AlertStrategy 结构中的 autoClose 字段。

下面介绍了缺失数据字段的不同选项:

API
evaluationMissingData 字段
总结 详情
EVALUATION_MISSING_DATA_UNSPECIFIED 未结突发事件保持未解决状态。
系统不会打开新的突发事件。

对于满足条件,当数据不再到达时,该条件会继续得到满足。如果某项突发事件因该条件而未结清,则该突发事件会保持未解决状态。当突发事件处于未结状态,且未收到任何数据时,自动关闭计时器会在延迟至少 15 分钟后启动。如果计时器超时,突发事件将被关闭。

对于不符合的条件,当数据不再到达时,不再继续满足该条件。

EVALUATION_MISSING_DATA_ACTIVE 未结突发事件保持未解决状态。
您可以创建新的突发事件。

对于满足条件,当数据不再到达时,该条件会继续得到满足。如果某项突发事件因该条件而未结清,则该突发事件会保持未解决状态。如果突发事件处于未结状态,并且自动关闭时长为 24 小时都没有数据到达,则系统会关闭突发事件。

对于不符合的条件,此设置会使指标阈值条件的行为类似于 metric-absence condition。如果数据未在“时长”字段指定的时间内到达,则条件评估为满足。对于具有一个条件的提醒政策,满足该条件会导致打开突发事件。

EVALUATION_MISSING_DATA_INACTIVE 未结突发事件已关闭。
系统不会打开新的突发事件。

对于满足的条件,当数据不再到达时,条件不再满足。如果某项突发事件因该条件而未结清,则该突发事件会被关闭。

对于不符合的条件,当数据不再到达时,不再继续满足该条件。

您可以通过执行以下任一操作,最大限度地减少由于缺少数据而导致的问题:

  • 请与您的第三方云服务提供商联系,了解缩短指标收集延迟时间的方法。
  • 在条件中使用较长的考量时长。如果使用较长的时间范围,则存在缺点:会导致提醒政策响应速度变慢。
  • 选择收集延迟时间较短的指标:

    • Monitoring 代理指标 - 尤其是当代理在第三方云端的虚拟机实例上运行时。
    • 自定义指标 - 当您直接将其数据写入 Cloud Monitoring 时。
    • 基于日志的指标 - 如果日志收集不会延迟。

如需了解详情,请参阅 Monitoring 代理概览使用自定义指标以及基于日志的指标

每项政策的通知和事件数

如需阻止 Monitoring 为提醒政策创建突发事件和发送通知,一种选择是停用此政策。另一种方法是创建延后,并在延后条件中包含此政策。延后生效后,相应政策不会创建突发事件或发送通知。

启用政策后,如果它们与有效延后的条件不一致,就会创建突发事件并发送通知。本部分介绍了每项政策的未结突发事件数量限制,以及何时可能会收到有关同一突发事件的多个通知的限制。

每项政策的未结突发事件数量

一项提醒政策可应用于多个资源,而影响所有资源的问题可触发该政策并为每个资源创建突发事件。 系统会为每个时间序列创建一个突发事件,从而导致条件得到满足。

为防止系统过载,将单项政策可同时创建的突发事件数限制为 5000。

例如,假设一项应用于 2000(或 20000)个 Compute Engine 实例的政策,并且每个实例都满足提醒条件。Monitoring 将未结突发事件的数量限制为 5000 个。在满足该政策的未结突发事件之前,满足所有其余条件。

每个突发事件的通知数

默认情况下,当时间序列促使满足条件时,系统会发送通知。如果出现以下任一情况,您可能会收到多条通知:

  • 一个条件是监控多个时间序列。

  • 一项政策包含多个条件:

    • 满足所有条件:满足所有条件后,政策会在每个符合条件的结果中发送通知,并创建事件。例如,假设您的政策具有两个条件,并且每个条件都在监控一个时序。此政策被触发时,您会收到两条通知,并会看到两个突发事件。

    • 满足任意条件:每次满足新的条件组合时,政策都会发送通知。例如,假设满足 ConditionA 的条件,突发事件随即会打开,并且系统会发送通知。若后续测量结果同时满足条件 A 和条件 B,则突发事件仍然保持未解决状态,然后发送另一条通知。

使用 Cloud Monitoring API 创建的提醒政策会在满足条件时以及满足条件时通知您。默认情况下,使用 Google Cloud Console 创建的提醒政策会在事件打开时通知您。事件关闭后,系统不会通知您。您可以启用突发事件关闭通知。

关于已停用提醒政策的通知

停用提醒政策后,政策会继续评估其条件。不过,系统不会创建突发事件,也不会发送通知。

启用已停用的政策后,Monitoring 会检查最近的时长窗口内所有条件的值。最近的时长可能包括在该政策启用之前、期间和之后获取的数据。政策在恢复后可立即触发,即使时长较长也是如此。

例如,假设您有用于监控特定进程的提醒政策,并且已停用此政策。在接下来的一周内,该过程会停止,并且由于此政策已停用,您不会收到通知。如果您立即重启进程并启用提醒政策,则 Monitoring 会识别出该进程在前五分钟内未启动,因此打开了一个突发事件。

如需在停用提醒政策后关闭待解决的问题,请将相应突发事件静音。如需了解此过程,请参阅将突发事件静音

符合有效延后条件的政策的通知

如果您想阻止提醒政策短时间发送通知,我们建议您创建延后,而不是停用该政策。例如,在对虚拟机 (VM) 执行维护之前,您可以创建一个延后,并将提醒实例的提醒政策添加到延后条件。

当提醒政策的条件触发并且该政策与有效延后的条件匹配时,系统不会创建突发事件,也不会发送任何通知。延后到期后,该政策可以创建突发事件并发送通知。

通知延迟时间

通知延迟时间是指从问题首次开始出现一直到政策被触发时的延迟时间。

以下活动和设置会影响总体通知延迟时间:

  • 指标收集延迟:Cloud Monitoring 收集指标值所需的时间。对于 Google Cloud 值,大多数指标在收集后的 60 秒内不可见;但是,延迟时间取决于指标。提醒政策计算需要额外的 60 到 90 秒延迟。对于 AWS CloudWatch 指标,可见性延迟时间可能为几分钟。对于正常运行时间检查,这可能是平均两分钟(从时长窗口结束算起)。

  • 时长窗口:为条件配置的窗口。 只有在时长窗口中满足某个条件时,才满足条件。例如,如果将时长窗口设置为 5 分钟,会导致通知在事件首次发生后至少五分钟内出现延迟。

  • 通知到达时间:电子邮件和短信等通知渠道本身可能会遇到网络延迟或与传送内容无关的其他延迟,有时会将近几分钟。在某些渠道上(例如短信和 Slack),无法保证消息一定会成功传送。

后续步骤