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

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

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

校准时间段和持续时间设置

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

校准时间段

注意 ：Cloud Monitoring 始终为指标缺失条件使用 24 小时的校准时间段。

校准时间段是从特定时间点算起的回溯间隔。校准器是用于将回溯期内的各点合并为已校准值的函数。例如，当校准时间段为五分钟时，下午 1:00，校准时间段包含在中午 12:55 到下午 1:00 之间接收的样本。在下午 1:01，校准时间段滑动一分钟，并包含在中午 12:56 到下午 1:01 之间收到的样本。

Google Cloud 控制台

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

如需详细了解可用的函数，请参阅 API 参考文档中的 Aligner。一些校准器函数既会校准数据，也会将数据从一种指标种类或类型转换为另一种。如需了解详细说明，请参阅种类、类型和转换。

API

您可以通过在 MetricThreshold 和 MetricAbsence 结构中设置 aggregations.alignmentPeriod 和 aggregations.perSeriesAligner 字段来配置对齐字段。

如需详细了解可用的函数，请参阅 API 参考文档中的 Aligner。一些校准器函数既会校准数据，也会将数据从一种指标种类或类型转换为另一种。如需了解详细说明，请参阅种类、类型和转换。

为说明校准时间段对提醒政策中的条件的影响，请设想一个指标阈值条件，它以一分钟的采样周期监控指标。假设校准时间段设置为 5 分钟，并且校准器设置为 sum。此外，假设当时时序的校准值在至少三分钟内大于 2 时，并且每分钟评估一次条件。下图说明条件的多次顺序评估：

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

考量时长

使用“时长”或“考量时长”可防止由于单次测量或预测而满足条件。例如，假设某个条件的持续时间字段设置为 15 分钟。下面根据类型描述了条件的行为：

• 对于单个时序，在 15 分钟间隔内的每个校准测量结果都超出阈值时，满足指标阈值条件。
• 如果时序在 15 分钟间隔内没有数据到达，则满足指标缺失条件。
• 如果在 15 分钟内生成的每个预测都预测时序将超出预测期内的阈值，则满足预测条件。

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

Google Cloud 控制台

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

API

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

上图显示了对指标阈值条件的三次评估。在时间 start + 2 minutes 时，校准值大于阈值；但由于时长设置为三分钟，因此不满足条件。下图展示了条件的下一次评估结果：

即使校准值在时间 start + 2 minutes 大于阈值，系统也会在校准值持续三分钟内大于阈值之前满足条件。该事件发生在 start + 5 minutes 时间。

每当测量或预测不符合条件时，条件就会重置其时长窗口。此行为如以下示例所示：

示例：此提醒政策包含一个指标阈值条件，用于指定 5 分钟时长窗口。

如果 HTTP 响应延迟时间超过两秒，
并且延迟时间持续五分钟以上，
则创建突发事件并向您的支持团队发送电子邮件。

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

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

4. 在接下来连续五分钟的时段内，HTTP 延迟时间大于两秒，因此满足条件。

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

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

设置校准时间段和持续时间的最佳实践

校准时间段决定了与校准器合并的样本数量：

• 指标类型的校准时间段的最小值是该指标类型的采样周期。例如，如果指标类型每 300 秒进行一次采样，则校准时间段应至少为 300 秒。但是，如果您想合并 5 个样本，则应将校准时间段设置为 5 * 300 秒或 1,500 秒。

• 校准时间段的最大值比指标类型的提取延迟时间少 24 小时。例如，如果指标的提取延迟时间为 6 小时，则校准时间段的最大值为 18 小时。

时长窗口用于指定提醒的响应速度。例如，如果将指标缺失条件的考量时长设置为 20 分钟，则在满足该条件之前，20 分钟内不得有任何数据。为了实现更灵敏的提醒政策，请将时长设置为较小的值。对于指标阈值条件，如需获得响应最及时的提醒政策，请将时长设置为零。只需对齐一个值，即可满足这些类型的条件。

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

具有多个条件的政策

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

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

Google Cloud 控制台

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

API

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

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

Google Cloud 控制台 政策触发值	Cloud Monitoring API combiner 值	含义
满足任意条件	OR	如果任何资源导致满足任何条件，则系统会创建一个突发事件。
满足所有条件 ，即便每个条件对应不同的 资源 （默认）	AND	如果满足每个条件，即使不同资源满足这些条件，也会创建突发事件。
满足所有条件	AND_WITH_MATCHING_RESOURCE	如果同一个资源导致满足每个条件，则系统会创建一个突发事件。此设置是最严格的组合选择。
注意：提醒政策使用标签值来标识导致条件得到满足的资源。对于使用此组合器创建突发事件或生成通知的提醒政策，必须满足以下条件： 每个条件都必须监控同一资源。例如，对于所有条件，资源类型设置为 gce_instance。 对于所有条件而言，聚合后提供的受监控资源标签必须相同。例如，对于 gce_instance 资源，标签为 project_id、instance_id 和 zone。如果一个条件按 zone 分组，则所有条件都必须按 zone 分组。 如需查看受监控资源及其标签的列表，请参阅受监控的资源类型。

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

示例

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

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

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

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

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

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

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

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

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

部分指标数据

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

Google Cloud 控制台

您可以配置 Monitoring 在数据停止到达时如何评估指标阈值条件。例如，当突发事件尚未解决，但预期的测量结果未到达时，您是希望 Monitoring 让突发事件保持未结状态，还是立即将其关闭？同样，当数据停止到达且没有突发事件未解决时，您是否希望创建突发事件？最后，在数据停止到达后，突发事件应保持未解决状态多长时间？

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

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

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

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

Google Cloud 控制台 “评估缺失数据”字段	摘要	详情
缺少空数据	未结突发事件保持开放状态。 系统不会创建新突发事件。	对于满足的条件，当数据停止到达时，将继续满足相应条件。对于这种情况，如果某个突发事件处于未解决状态，则该突发事件将保持未解决状态。如果某个突发事件处于未解决状态且没有任何数据到达，自动关闭计时器会在至少 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。如果数据在“duration”字段指定的时间内未到达，则评估为已满足条件。对于包含一个条件的提醒政策，满足某个条件会导致创建突发事件。
EVALUATION_MISSING_DATA_INACTIVE	未结突发事件已关闭。 系统不会创建新突发事件。	对于满足的条件，当数据停止到达时，相应条件便会停止满足。对于这种情况，如果某个突发事件处于未解决状态，则该突发事件将关闭。 如果不符合条件，则当数据停止到达时，系统仍会继续不满足条件。

通过执行以下任一操作，您可以尽可能减少因缺失数据而导致的问题：

• 请与您的第三方云服务提供商联系，了解如何缩短指标收集延迟时间。
• 在条件中使用较长的考量时长。使用较长的持续时间的缺点会导致提醒政策的响应速度变慢。

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

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

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

通知和突发事件（每项政策）

如需阻止 Monitoring 创建突发事件并针对提醒政策发送通知，请创建延后，并将提醒政策添加到延后条件中。延后启用后，提醒政策不会创建突发事件，也不会发送通知。

如果政策已启用且不符合有效延后的条件，则系统可能会创建突发事件并发送通知。本部分介绍了每项政策的未结突发事件数量限制，以及何时您可能会看到有关同一突发事件的多个通知。

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

提醒政策可以应用于许多资源，而影响所有资源的问题可能会导致提醒政策为每个资源创建突发事件。系统会针对使条件满足的每个时序开设一个突发事件。

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

例如，假设一个政策应用于 2,000 个 Compute Engine 实例，并且每个实例都会导致满足提醒发出条件。Monitoring 将未结突发事件的数量限制为 1,000。除非该政策的一些未解决突发事件关闭，否则系统会忽略满足的所有其余条件。

注意 ：如果您为某个提醒政策有一个未结突发事件，并且导致突发事件的时序再次超过条件阈值，那么当该突发事件仍在发生时，系统便不会创建其他突发事件。Monitoring 会为提醒政策中的每个时序仅维护一个未结突发事件。

每项政策的通知数量

默认情况下，当时时序导致满足某个条件时，系统会发送通知。如果出现以下任一情况，您可能会收到多条通知：

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

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

  • 满足所有条件：当满足所有条件时，对于使条件满足的每个时序，Monitoring 会发送通知并创建突发事件。例如，假设您的政策包含两个条件，每个条件都监控一个时序。满足所有条件后，您会收到两条通知，并且会看到两个突发事件。

  • 满足任一条件：每当满足条件时，提醒政策都会发送通知。例如，假设您的政策包含两个条件，每个条件都监控一个时序。假设满足第一个条件。这会导致一个突发事件被打开并发送通知。当后续测量导致满足第二个条件时，如果突发事件仍处于未解决状态，系统会发送另一条通知。

注意 ：如果提醒政策包含多个条件，则不能将其配置为发送单个通知并创建单个突发事件。

使用 Cloud Monitoring API 创建的提醒政策会在满足条件和不再满足条件时通知您。默认情况下，使用 Google Cloud 控制台创建的提醒政策会在突发事件发生时通知您。它们不会在突发事件关闭时通知您。您可以启用突发事件关闭通知。

注意：您无法使用 Monitoring API 更改突发事件关闭通知的传送。

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

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

启用已停用的政策后，Monitoring 会检查最近一个考量时长内所有条件的值。最近时长可能包括政策启用前、启用期间和启用后获取的数据。即使政策的持续时间较长，在恢复政策后也可以立即满足已停用政策的条件。

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

停用提醒政策后，未解决的事件将保持打开状态，直到自动关闭时长到期。当您延后提醒政策时，与该政策相关的所有未解决的突发事件都会被关闭。但是，延后结束后，系统可能会创建新的突发事件。如需了解详情，请参阅延后通知和提醒。

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

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

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

重复发送通知

如需向通知接收者提醒其未结和已确认的突发事件，请设置重复通知。此功能对于监控那些在资源耗尽时可能导致服务失败的关键资源的提醒政策非常有用。例如，您可以为监控可用磁盘空间量的提醒政策设置重复通知。

默认情况下，当突发事件出现时，提醒政策会向每个通知渠道发送一条通知。不过，您可以更改默认行为，并将提醒政策配置为向所有或部分提醒政策通知渠道重新发送通知。系统会针对状态为“未结”或“已确认”的突发事件发送这些重复的通知。这些通知的时间间隔必须至少为 30 分钟且不超过 24 小时（以秒为单位）。

注意 ：您无法为基于日志的提醒设置重复通知。

Google Cloud 控制台

您无法在 Google Cloud 控制台中配置重复通知。请改用 Google Cloud CLI 或 API。

API

向您的 AlertStrategy 对象添加至少一个 NotificationChannelStrategy 对象。NotificationChannelStrategy 对象有两个字段：

• renotifyInterval：两次重复通知之间间隔的时间（以秒为单位）。

  您可以随时更改 renotifyInterval 字段的值。如果您更改时间间隔后，如果与提醒政策相关的突发事件处于未解决状态，则提醒政策会再发送一次关于突发事件的通知，然后重新开始间隔时间段。

• notificationChannelNames：通知渠道资源名称的数组，格式为 projects/PROJECT_ID/notificationChannels/CHANNEL_ID 格式的字符串。这些通知渠道会按照 renotifyInterval 值定义的时间间隔接收重复通知。

  资源名称渠道 ID 是一个数值。 如需了解如何检索渠道 ID，请参阅列出项目中的通知渠道。

例如，以下 JSON 示例展示了一个提醒策略，该策略配置为每 1800 秒（30 分钟）向列出的通知渠道发送重复通知：

  "alertStrategy": {
    "notificationChannelStrategy": [
      {
        "notificationChannelNames": [
          "projects/PROJECT_ID/notificationChannels/CHANNEL_ID"
        ],
        "renotifyInterval": "1800s"
      }
    ]
  }

如需详细了解如何使用 API 创建提醒政策，请参阅使用 API 创建提醒政策。

如需在一段时间内停止重复的通知，请停用或创建提醒政策的延后。如需完全停止重复的通知，请使用 API 修改提醒政策并移除 NotificationChannelStrategy 对象。

延迟时间

延迟时间是指 Monitoring 对指标进行采样与指标数据点作为时序数据可见之间的延迟时间。延迟时间会影响通知的发送时间。例如，如果受监控指标的延迟时间最长为 180 秒，则在提醒政策条件评估结果为 true 后，Monitoring 在最长 180 秒内不会创建突发事件。如需了解详情，请参阅指标数据的延迟时间。

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

• 指标收集延迟：Monitoring 收集指标值所需的时间。对于 Google Cloud 值，大多数指标在收集后的 60 秒内都是不可见的；但是，延迟取决于指标。提醒政策的计算需要额外增加 60 到 90 秒的延迟。对于 AWS CloudWatch 指标，可见性延迟可能会是几分钟。对于拨测，这可能是平均两分钟（从考量时长结束时算起）。

• 考量时长：为条件配置的时间期限。 只有在整个考量时长内某个条件为 true 时，才满足条件。例如，如果将时长设置为 5 分钟，那么通知在事件首次发生后至少会延迟 5 分钟。

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

后续步骤

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

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

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