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

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

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

校准期和重新测试期

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

校准时间段

在提醒政策监控时间序列数据之前，必须对其进行正则化处理，以便提醒政策有定期间隔的数据可供评估。正则化过程称为“对齐”。

校准包含两个步骤：

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

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

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

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

Monitoring 会按如下方式配置对齐期：

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

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

重新测试窗口

提醒政策的条件具有重新测试时段，可防止因单个测量结果或预测结果而满足条件。例如，假设某个条件的重新测试时间范围设置为 15 分钟。以下内容介绍了条件的行为（基于其类型）：

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

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

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

即使校准值在时间 start + 2 minutes 超过阈值，在校准值超过三分钟的阈值前也不满足条件。该事件发生的时间为 start + 5 minutes。

每当测量结果或预测结果不满足条件时，条件都会重置其重新测试期限。以下示例展示了此行为：

示例：此提醒政策包含一个指标阈值条件，该条件指定了五分钟的重新测试时间范围。

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

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

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

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

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

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

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

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

• 指标类型的校准时间段的最小值为该指标类型的采样时间段。例如，如果指标类型每 300 秒采样一次，则校准时间段应至少为 300 秒。不过，如果您想合并 5 个样本，则应将校准时间段设置为 5 * 300 秒或 1500 秒。

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

使用重新测试期限可指定提醒的响应速度。例如，如果您将指标缺失条件的重新测试期限设置为 20 分钟，则必须在 20 分钟内没有数据，该条件才会满足。如需让提醒政策的响应速度更快，请将重新测试期限设置为较小的值。对于指标阈值条件，为了让提醒政策的响应速度最快，请将重新测试期限设为 0。只要有一个对齐的值，就会满足这类条件。

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

具有多个条件的政策

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

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

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

Google Cloud 控制台 政策触发条件值	Cloud Monitoring API combiner 值	含义
满足任意条件	OR	如果任何资源导致满足任何条件，则系统会创建一个突发事件。
满足所有条件 ，即便每个条件对应不同的 资源 （默认）	AND	如果满足每个条件，则系统会创建一个突发事件，即使有另一个资源导致满足这些条件也是如此。
满足所有条件	AND_WITH_MATCHING_RESOURCE	如果同一个资源导致满足每个条件，则系统会创建一个突发事件。此设置是最严格的组合选择。

在此上下文中，术语 met 表示条件的配置评估为 true。例如，如果配置为 Any time series is greater than 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 使用率超过阈值并持续 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 得到满足。

部分指标数据

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

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

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

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

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

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

Monitoring 何时发送通知和创建突发事件

当时时序促使满足条件时，Cloud Monitoring 会发送通知。系统会将通知发送到所有通知渠道。您无法将通知限制为仅发送到特定渠道或政策渠道的一部分。

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

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

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

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

  • 满足所有条件：满足所有条件后，提醒政策会在每个符合条件的结果中发送通知，并创建事件。

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

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

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

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

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

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

• 提醒政策已停用。
• 提醒政策已暂停。
• 监控功能已达到开放式支持请求的数量上限。

停用的提醒政策

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

当您启用停用的政策时，Monitoring 会评估最近的重新测试时间范围中所有条件的值。最近的重新测试时间段可能包括在启用政策之前、期间和之后所取得的数据。停用的政策在恢复后可能会立即满足相关条件，即使重新测试期限较长也是如此。

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

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

已暂停的提醒政策

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

当您暂停提醒政策时，Monitoring 会关闭与该政策相关的所有未结突发事件。Monitoring 可以在暂停期结束后打开新的突发事件。如需了解详情，请参阅推迟通知和提醒。

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

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

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

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

因此，单个通知渠道一次最多只能接收 1,000 条通知。如果您的提醒政策有多个通知渠道，则此限制会分别应用于每个通知渠道。

延迟时间

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

以下活动和设置会影响延迟时间：

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

• 重新测试窗口：为条件配置的时间长度。只有在整个重新测试期限内条件均为 true 时，才会满足条件。例如，如果重新测试时间范围设置为 5 分钟，则从事件首次发生时起算，通知会至少延迟 5 分钟。

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

后续步骤

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

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

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