提醒行为

提醒政策存在于动态且复杂的环境当中,因此,要有效地使用这些政策,就必须了解可能影响其行为的一些可变因素。由条件监控的指标和资源、条件的考量时长、通知渠道,这些都可能会产生影响。

本页面提供了一些额外的信息,帮助您理解提醒政策的行为。

校准时间段和时长

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

校准时间段

校准时间段是从特定时间点算起的回溯间隔。例如,如果校准时间段为 5 分钟,则在下午 1:00,校准时间段包含在中午 12:55 到下午 1:00 之间收到的样本。在下午 1:01,校准时间段滑动一分钟,并包含在中午 12:56 到下午 1:01 之间收到的样本。

为了说明校准时间段对提醒政策中的条件的影响,请考虑使用以下条件:使用采样时间段一分钟监控指标。假设将校准时间段设置为 5 分钟,并且将校准器设置为 sum。最后,假设在时间序列的校准值在 3 分钟内大于 2 时满足条件,并且每分钟评估条件。

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

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

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

考量时长

您可以使用时长或考量时长来防止单个测量结果满足条件的情况。如果您使用的是 Google Cloud Console,则配置窗格中的 For 字段对应于考量时长。

上图说明条件的三次评估。在时间 start + 2m,校准值超过阈值;但是,由于将考量时长设置为三分钟,因此不满足条件。下图说明条件的下一次评估的结果:

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

如图所示,即使校准值在时间 start + 2m 超过阈值,在校准值超过三分钟的阈值前也不满足条件。发生这种情况的时间为 start + 5m

该图说明了校准时间段决定了校准器合并的数据样本数量。如果您选择较长的时间段,则系统会合并许多样本。如果您选择较短的时间段,则可能间隔中只有一个数据点。相比之下,考量时长指定在满足条件之前,校准值必须超过阈值的时长。如果将考量时长设置为 0,则超过阈值的单个校准值意味着满足条件。

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

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

示例:此政策指定了五分钟的考量时长。

如果 HTTP 响应延迟时间超过两秒,
并且延迟时间超过该阈值五分钟,
则打开一个突发事件,并向支持团队发送电子邮件。

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

  1. HTTP 延迟时间低于两秒。
  2. 在接下来连续三分钟的时间段内,HTTP 延迟时间超过两秒。
  3. 在下一次测量中,延迟时间低于两秒,因此条件会重置考量时长。
  4. 在接下来连续五分钟的时间段内,HTTP 延迟时间超过两秒,因此满足条件并触发政策。

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

具有多个条件的政策

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

如果您使用的是 Cloud Monitoring API,或者您的提醒政策有多个条件,那么您必须指定满足各个条件的时间。当满足某个条件时,会导致系统创建一个事件,且可能导致系统创建一个突发事件:

  • 如果您使用的是 Google Cloud Console,请使用 政策触发条件 (Policy triggers) 字段。
  • 如果您使用的是 Cloud Monitoring API,请使用 combiner 字段。

下表列出了 Cloud Console 中的设置、Cloud Monitoring API 中的等效值以及每个设置的说明:

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

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

在此上下文中,术语 met 表示条件的配置评估为 true。例如,如果配置为 Any time series is above 10 for 5 minutes,则当此语句评估为 true 时满足条件。

示例

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

  • 名为 CPU usage is too high 的条件用于监控实例的 CPU 使用率。当任何实例的 CPU 使用率超过 100ms/s 并持续 1 分钟时,则满足此条件。
  • 名为 Excessive utilization 的条件用于监控实例的 CPU 利用率。当任何实例的 CPU 使用率超过 1 分钟的 60% 时,则满足此条件。

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

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

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

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

    提醒一下,如果 vm2 导致条件 CPU usage is too high 得到满足,也会导致系统创建突发事件。这是因为导致条件 CPU usage is too high 得到满足和导致条件 CPU usage is too high 得到满足的 vm1 和 vm2 是不同的事件。

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

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

停用的提醒政策

通过停用和启用政策,您可以暂时停止和重启提醒政策。例如,如果您有一项提醒政策,该政策会在某个进程中断超过 5 分钟时通知您,那么当您关闭该进程进行升级或其他维护时,可以将该提醒政策停用。

停用提醒政策可防止政策触发或解决突发事件,但不会阻止 Cloud Monitoring 评估政策条件并记录结果。如果要停用提醒政策且要解决处于待解决状态的问题,则必须手动解决这些突发事件。如需了解该流程的相关信息,请参阅已关闭的突发事件

假设将受监控的进程关闭 20 分钟以进行维护。如果您重启该进程并立即重新启用提醒政策,则政策会识别出该进程在刚刚过去的 5 分钟内未启动,并会创建一个事件。

当停用的政策重新启用时,Monitoring 会检查最近的 考量时长 中所有条件的值,其中可能包括在暂停时间间隔之前、期间和之后所取得的数据。政策可能会在取消暂停后立即触发,即使考量时长较长也是如此。

异常事件

提前或错误触发的提醒政策(特别是具有指标缺失或“小于”阈值条件的政策)可能会出现在 Alerting 窗口的 Incidents 窗格上。

当数据存在缺口时,会发生这种情况,但有时很难发现这种缺口。有时候缺口很模糊,而有时候它会被纠正。

例如,在图表中,数据中的缺口会被插值。如果丢失几分钟的数据,则图表会连接缺失的点,以获得视觉上的连续性。基础数据中的这种缺口可能足以触发提醒政策。

如果基于日志的指标中的点出现延迟,系统可能会对其进行回填(针对过去最长 10 分钟的数据点进行回填)。这可有效地纠正缺口;当数据最终到达时,会填补缺口。因此,基于日志的指标中一个再也看不见的缺口可能已经导致了提醒政策触发。

指标缺失和“小于”阈值条件会实时评估,查询延迟时间很短。在评估条件到相应突发事件在 Monitoring 中可见这段时间内,条件的状态可能会发生变化。

部分指标数据

如果缺少测量结果(例如,如果几分钟都没有 HTTP 请求),则政策会使用最后记录的值来评估条件。

示例

  1. 一个条件指定连续五分钟 HTTP 延迟时间为两秒或更长。
  2. 在连续三分钟的时段内,HTTP 延迟时间为三秒。
  3. 在接下来的连续两分钟内,没有 HTTP 请求。 在这种情况下,条件会将最后一次测量结果(三秒)转入这两分钟的记录。
  4. 在总共五分钟之后,即使最后两分钟没有数据,政策也会触发。

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

采取以下任一做法,可以最大限度减少这些问题:

  • 联系您的第三方云服务提供商,了解是否有办法减轻指标收集延迟的问题。
  • 在条件中使用较长的考量时长。但这有一个缺点,即会使提醒政策响应不及时。
  • 选择收集延迟时间较短的指标:

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

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

每个政策的突发事件

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

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

例如,如果某项政策适用于 2000(或 20000)个 Compute Engine 实例,并且每个实例都导致提醒条件得到满足,那么系统只会创建 5000 个突发事件。系统将忽略满足的其余任何条件,直到该政策的一些未结突发事件得到解决为止。

每次事件的通知数

系统会向导致条件得到满足的每个时间序列发送通知。当该时间序列不再导致条件得到满足时,系统会发送另一条通知。当相应条件不再满足时,突发事件会得到解决。

如果政策包含多个条件,则可能会发送多条通知,具体取决于您设置政策的方式:

  • 如果只有满足 全部 条件才会触发政策,则政策仅会在最初创建突发事件时发送通知。

  • 如果在满足任意条件时触发政策,则政策会在每次满足新的条件组合时发送通知。例如:

    1. 满足条件 A 时,创建一个事件并发送一条通知
    2. 当后续测量结果同时满足条件 A 和条件 B 时,事件仍然处于未解决状态。在这种情况下,事件会保持未解决状态,并会发送另一条通知。

通知延迟时间

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

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

  • 指标收集延迟:Cloud Monitoring 收集指标值所需的时间。对于 Google Cloud 值,这通常可以忽略不计。对于 AWS CloudWatch 指标,这可能需要几分钟。对于正常运行时间检查,这可能是平均两分钟(从考量时长结束时起)。

  • 考量时长:为条件配置的时间长度。请注意,只有在整个考量时长中条件均为 true 时,才会满足条件。例如,如果您指定了一个五分钟的时间段,则通知会比事件首次发生时至少延迟五分钟。

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

后续步骤