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

使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

本文档介绍了校准时间段和重新测试窗口如何确定何时满足条件、提醒政策如何组合多个条件以及提醒政策如何替换缺失的数据点。它还介绍了政策的未结突发事件数量上限、每个突发事件的通知数量以及导致通知延迟的原因。

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

校准时间段和重新测试窗口

在确定是否满足提醒政策的条件时，Cloud Monitoring 会评估校准时间段和重新测试窗口。

校准时间段

在提醒政策监控时序数据之前，必须对数据进行正则化处理，以便提醒政策具有可进行评估的常规间隔数据。正则化过程称为“校准”。

校准包含两个步骤：

• 将时序划分为固定的时间间隔，也称为数据分桶。该间隔称为校准时间段。

• 计算校准时间段内点的单个值。 您可以选择单个点的计算方式；您可以对所有值求和、计算平均值或使用最大值。组合数据点的函数称为“校准器”。组合结果称为“校准值”。

  如需详细了解校准，请参阅校准：序列内正则化。

例如，如果校准时间段为 5 分钟，则在下午 1:00，校准时间段包含在中午 12:55 到下午 1:00 之间收到的样本。在下午 1:01，校准时间段滑动一分钟，并包含在中午 12:56 到下午 1:01 之间收到的样本。

Monitoring 会按如下方式配置校准时间段：

为了说明校准时间段对提醒政策中的条件的影响，请考虑一个指标阈值条件，该条件使用 1 分钟的采样时间段来监控指标。假设将校准时间段设置为 5 分钟，并且将校准器设置为 sum。此外，假设在时序的校准值至少持续 3 分钟大于 2 时满足条件，并且每分钟评估一次条件。在此示例中，校准时间段为 2 分钟，而下一部分中介绍的重新测试窗口为 3 分钟。下图说明条件的多次顺序评估：

图中的每一行都说明条件的单次评估。系统会显示时间序列数据。校准时间段中的点以蓝点显示；较早的点为黑色。每行显示校准值，以及此值是否大于阈值 2。对于标记为 start 的行，校准值计算结果为 1（小于阈值）。在下一次评估中，校准时间段内的样本总和为 2。在第三次评估中，总和为 3，由于此值大于阈值，因此会启动重新测试窗口的计时器。

重新测试窗口

提醒政策的条件具有重新测试窗口，可防止单个测量或预测满足条件。例如，假设某个条件的重新测试窗口设置为 15 分钟。下面根据条件的类型介绍了其行为：

• 如果对于单个时序，15 分钟间隔内的每个校准测量值都违反阈值，则满足指标阈值条件。
• 如果 15 分钟间隔内一直没有收到时序的数据，则满足指标缺失条件。
• 如果在 15 分钟窗口内生成的每个预测都预测时序将在预测窗口内违反阈值，则满足预测条件。

对于包含一个条件的政策，当满足条件时，系统会开启突发事件并发送通知。在继续满足条件期间，这些突发事件会保持未结状态。

上图说明了指标阈值条件的三次评估。在时间为 start + 2 minutes 时，校准值大于阈值；但是，由于重新测试窗口设置为 3 分钟，因此不满足条件。下图说明条件的下一次评估的结果：

即使校准值在时间为 start + 2 minutes 时大于阈值，但在校准值大于阈值的持续时间达到 3 分钟之前，不会满足条件。该事件发生的时间为 start + 5 minutes。

每当测量或预测不满足条件时，条件都会重置其重新测试窗口。以下示例说明了此行为：

示例：此提醒政策包含一个指标阈值条件，该条件指定了时长为 5 分钟的重新测试窗口。

如果 HTTP 响应延迟时间超过 2 秒，
并且延迟时间持续 5 分钟大于阈值，
系统会开启一个突发事件，并向支持团队发送电子邮件。

以下内容说明了重新测试窗口如何影响条件的评估：

1. HTTP 延迟时间低于 2 秒。
2. 在接下来连续 3 分钟的时间段内，HTTP 延迟时间超过 2 秒。
3. 在下一次测量中，延迟时间低于 2 秒，因此条件会重置重新测试窗口。

4. 在接下来连续 5 分钟的时间段内，HTTP 延迟时间超过 2 秒，因此满足条件。

   由于提醒政策只有一个条件，因此 Monitoring 会在满足该条件时发送通知。

请将重新测试窗口设置为足够长的时间，以便最大限度地减少假正例，但也应足够短，以便确保及时开启突发事件。

有关设置校准时间段和重新测试窗口的最佳实践

校准时间段决定了使用校准器进行组合的样本数量：

• 指标类型的校准时间段的最小值是该指标类型的采样周期。例如，如果指标类型每 300 秒采样一次，则校准时间段应至少为 300 秒。不过，如果您要组合 5 个样本，请将校准时间段设置为 5 * 300 秒（即 1500 秒）。

• 校准时间段的最大值是 24 小时减去指标类型的注入延迟时间。例如，如果指标的注入延迟时间为 6 小时，则校准时间段的最大值为 18 小时。

使用重新测试窗口可指定提醒的响应速度。例如，如果您将指标缺失条件的重新测试窗口设置为 20 分钟，则必须持续 20 分钟没有数据才能满足条件。如需获得响应速度更快的提醒政策，请将重新测试窗口设置为更小的值。对于指标阈值条件，如需获得响应速度最快的提醒政策，请将重新测试窗口设置为零。单个校准值会导致满足这些类型的条件。

提醒政策条件按固定频率进行评估。您对校准时间段和重新测试窗口做出的选择不会影响条件的评估频率。

具有多个条件的政策

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

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

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

Google Cloud 控制台 政策触发器值	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 使用率持续 1 分钟超过 100ms/s 时，满足此条件。
• 名为 Excessive utilization 的条件用于监控实例的 CPU 利用率。当任何实例的 CPU 利用率持续 1 分钟超过 60% 时，满足此条件。

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

接下来，假设 vm1 的 CPU 使用率超过 100ms/s，持续 1 分钟。由于 CPU 使用率持续 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 得到满足的 vm1 和 vm2 是不同的事件。

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

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

部分指标数据

当时序数据停止到达或数据延迟时，Monitoring 会将数据归类为“缺失”。缺失的数据可能会导致无法关闭突发事件。来自第三方云服务提供商的数据延迟时间可能长达 30 分钟，其中 5-15 分钟的延迟时间最为常见。延迟时间过长（比重新测试窗口更长）可能会导致条件进入“未知”状态。当数据最终到达时，Monitoring 可能已经丢失了条件的一些近期历史记录。由于一旦数据到达，就再也没有证据表明出现过延迟，因此事后对时间序列数据进行检查可能不会揭示这个问题。

采取以下任一做法，可以最大限度减少因缺失数据而导致的问题：

• 与您的第三方云服务提供商联系，了解如何缩短指标收集延迟时间。
• 在条件中使用更长的重新测试窗口。使用更长的重新测试窗口有一个缺点，即会使提醒政策响应不及时。

• 选择收集延迟时间较短的指标：

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

如需了解详情，请参阅 Monitoring 代理概览、用户定义的指标概览以及基于日志的指标。

Monitoring 发送通知和创建突发事件的情况

当时序导致条件得到满足时，Cloud Monitoring 会发送通知。通知会发送到所有通知渠道。您无法将通知限制到特定渠道或政策渠道子集。

如果您配置了重复通知，系统会针对您的提醒政策将同一通知重新发送到特定通知渠道。

如果出现以下任一情况，您可能会收到与一个提醒政策相关的多条通知：

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

• 一个政策包含多个条件。在这种情况下，您收到的通知取决于提醒政策的多条件触发器的值：

  • 满足所有条件：当满足所有条件时，对于导致条件得到满足的每个时序，提醒政策都会发送通知并创建突发事件。

    当提醒政策包含多个条件时，您无法将 Cloud Monitoring 配置为仅创建一个突发事件并且仅发送一个通知。

  • 满足任意条件：当时序导致条件得到满足时，提醒政策会发送通知。

  如需了解详情，请参阅具有多个条件的政策。

使用 Cloud Monitoring API 创建的提醒政策也会在满足条件以及不再满足条件时通知您。使用 Google Cloud 控制台创建的提醒政策不会在不再满足条件时发送通知，除非您启用了该行为。

Monitoring 不发送通知或创建突发事件的情况

在以下情况下，当满足提醒政策的条件时，Monitoring 不会创建突发事件或发送通知：

• 提醒政策已停用。
• 提醒政策已延后。
• Monitoring 已达到未结突发事件最大数量上限。

停用的提醒政策

Monitoring 不会为已停用的提醒政策创建突发事件或发送通知。不过，Monitoring 会继续评估已停用提醒政策的条件。

当您启用已停用的政策时，Monitoring 会评估所有条件在最近的重新测试窗口中的值。最近的重新测试窗口可能包括在启用政策之前、期间和之后所取得的数据。即使重新测试窗口较大，已停用政策的条件也可能会在恢复政策后立即得到满足。

例如，假设您有一个用于监控特定进程的提醒政策，并且您停用了此政策。该进程在第二周发生故障，而由于提醒政策已停用，因此您未收到通知。如果您重启该进程并立即启用提醒政策，则 Monitoring 会识别出该进程在刚刚过去的 5 分钟内一直未启动，因而会开启一个突发事件。

与已停用的提醒政策相关的突发事件会保持为未结状态，直到该政策的自动关闭时长到期。

已延后的提醒政策

对于已延后的提醒政策，Monitoring 不会发送通知或创建突发事件。如果您想仅在短时间内阻止提醒政策发送通知，建议您延后提醒政策。例如，在对虚拟机 (VM) 执行维护之前，您可以创建一个延后，并将监控实例的提醒政策添加到延后条件中。

当您延后提醒政策时，Monitoring 会关闭与相应政策相关的所有未结突发事件。Monitoring 可以在延后到期后开启新的突发事件。如需了解详情，请参阅延后通知和提醒。

通知和未结突发事件的限制

一个提醒政策可应用于多个资源，而影响所有资源的问题可能会导致提醒政策为每个资源开启突发事件。系统会为导致条件得到满足的每个时序都开启一个突发事件。

为防止系统过载，单个政策可同时创建的突发事件数量限制为 1,000。

例如，假设某个政策应用于 2000 个 Compute Engine 实例，并且每个实例都导致提醒条件得到满足。Monitoring 将未结突发事件的数量限制为 1,000。系统将忽略满足的其余任何条件，直到该政策的一些未结突发事件关闭为止。

由于存在此限制，单个通知渠道一次最多可接收 1,000 条通知。如果您的提醒政策有多个通知渠道，则此限制会单独应用于每个通知渠道。

延迟时间

延迟时间是指从 Monitoring 对指标进行采样到指标数据点以时序数据的形式可见之间的延迟。延迟时间会影响通知的发送时间。例如，如果某个受监控的指标的延迟时间不超过 180 秒，那么在提醒政策条件评估为 true 后，Monitoring 最多在 180 秒后便会创建突发事件。如需了解详情，请参阅指标数据的延迟时间。

以下事件和设置会影响延迟时间：

• 指标收集延迟：Monitoring 收集指标值所需的时间。对于 Google Cloud 值，大多数指标在收集后 60 秒内都不会显示；不过，延迟取决于指标。提醒政策计算最多会额外延迟 5 分 30 秒。对于 AWS CloudWatch 指标，显示延迟可能为几分钟。对于拨测，此延迟平均为两分钟（从重新测试窗口结束时起算起）。

• 重新测试窗口：为条件配置的窗口。只有在整个重新测试窗口中条件均为 true 时，才会满足条件。例如，重新测试窗口设置为 5 分钟会导致从事件首次发生时算起，通知至少会延迟 5 分钟。

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

后续步骤

• 如需了解如何创建提醒政策，请参阅以下文档：

  • 创建指标阈值提醒政策
  • 创建指标缺失提醒政策
  • 创建预测指标值提醒政策
  • 使用 Monitoring API 创建提醒政策

• 如需了解各类提醒政策，请参阅示例政策。