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

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

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

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

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

校准时间段

在提醒政策监控时间序列数据之前，必须对其进行正则化，以便提醒政策定期评估要评估的数据。正则化过程称为alignment。

校准包含两个步骤：

• 将时序划分为有规律的时间间隔，也称为对数据进行分桶。间隔即为校准时间段。

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

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

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

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

Google Cloud 控制台

您可以通过在提醒条件页面上为以下字段选择一个值来配置校准时间段：

• 滚动窗口：指定要评估的时间范围。
• 滚动窗口函数：指定要对数据点窗口执行的数学函数。

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

API

您可以通过在 MetricThreshold 和 MetricAbsence 结构中设置 aggregations.alignmentPeriod 和 aggregations.perSeriesAligner 字段来配置校准时间段。

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

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

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

重新测试窗口

提醒政策的条件包含重新测试期，这会阻止单次测量或预测，无法满足条件。例如，假设某个条件的重新测试期设置为 15 分钟。下面根据条件类型描述了条件的行为：

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

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

Google Cloud 控制台

您可以在配置提醒触发器步骤中使用重新测试窗口字段来配置重新测试窗口。

API

您可以通过在 MetricThreshold 和 MetricAbsence 结构中设置名为 duration 的字段来配置重新测试窗口。

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

即使校准值在时间 start + 2 minutes 大于阈值，只要校准值超过阈值达三分钟，条件才会满足。该事件发生在 start + 5 minutes 时间。

每当测量结果或预测值不满足条件时，条件就会重置其重新测试窗口。以下示例演示了此行为：

示例：此提醒政策包含一个指标阈值条件，用于指定五分钟的重新测试期。

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

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

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 控制台

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

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 分组。 如需查看受监控资源及其标签的列表，请参阅受监控的资源类型。

在此上下文中，术语“满足”表示条件配置的评估结果为“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 分钟，则满足此条件。

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

接下来，假设 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，这也会导致创建突发事件。由于 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 在数据停止到达时如何评估指标阈值条件：

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

  重新测试窗口是 Cloud Monitoring API 中名为“时长”的字段。

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

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

Google Cloud 控制台 “评估缺失数据”字段	摘要	详情
缺少数据为空	未结突发事件保持未结状态。 新的突发事件不会被创建。	如果满足的条件，当数据不再到达时，条件将继续满足。如果突发事件针对此条件未结，则突发事件会保持未解决状态。如果突发事件未解决，但未收到任何数据，则自动关闭计时器会在延迟至少 15 分钟后启动。如果计时器过期，则事件已关闭。 对于不满足的条件，当数据不再到达时，不再满足条件。
缺失的数据点会被视为违反政策条件的值	未结突发事件保持未结状态。 可以创建新突发事件。	如果满足的条件，当数据不再到达时，条件将继续满足。如果突发事件针对此条件未结，则突发事件会保持未解决状态。如果突发事件在自动关闭时长加 24 小时内未到达，则突发事件会被关闭。 对于不符合的条件，此设置会导致指标阈值条件的行为类似于 metric-absence condition。如果数据未在重新测试窗口指定的时间内到达，则条件评估为满足。对于包含一个条件的提醒政策，满足该条件会导致创建突发事件。
缺失数据点被视为未违反政策条件的值	未结突发事件已关闭。 新的突发事件不会被创建。	对于满足的条件，当数据不再到达时，不再满足条件。如果某个突发事件符合此条件，则该突发事件会被关闭。 对于不满足的条件，当数据不再到达时，不再满足条件。

API

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

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

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

• 如需配置在数据停止到达后，在关闭未结突发事件之前等待的时间，请使用 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 发送通知并创建突发事件时

当时时序导致满足条件时，Cloud Monitoring 会发送通知。通知将发送到所有通知渠道。您不能将通知限制为仅特定渠道或政策中的一部分渠道。

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

如果满足以下任一条件，您可能会收到多个与一个提醒政策相关的独特通知：

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

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

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

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

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

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

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

当 Monitoring 未发送通知或未创建突发事件时

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

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

停用的提醒政策

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

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

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

与已停用的提醒政策相关的事件将保持未解决状态，直到该政策的自动关闭时长到期。

已延后的提醒政策

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

如果您延后提醒政策，Monitoring 会关闭与该政策相关的所有未结突发事件。Monitoring 可以在延后过期后创建新的突发事件。有关信息，请参阅暂停通知和提醒。

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

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

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

例如，假设一个政策应用于 2000 个 Compute Engine 实例，每个实例都会导致满足提醒发出条件。Monitoring 将未结突发事件的数量限制为 1000 个。系统会忽略满足的所有其余条件，直到该政策的一些未结突发事件结束为止。

受此限制的影响，单个通知渠道一次最多可以接收 1,000 条通知。如果您的提醒政策有多个通知渠道，那么此上限将分别应用于每个通知渠道。

注意 ：如果您有一个针对提醒政策未结的突发事件，并且触发该事件的时序再次超过条件阈值，那么当突发事件仍未解决时，便不会创建另一个突发事件。Cloud Monitoring 仅会为提醒政策中的每个时序保留一个未结突发事件。

延迟时间

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

以下事件和设置会导致延迟时间：

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

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

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

后续步骤

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

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

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