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

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

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

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

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

校准时间段

在提醒政策监控时间序列数据之前， 正则化，以便提醒政策定期评估要评估的数据。 正则化过程称为“对齐”。

校准包含两个步骤：

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

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

  如需详细了解对齐方式，请参阅 校准：系列内正则化。

例如，如果校准时间段为 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。对于带有 start，则校准后的值计算为 1，即小于阈值。 在下一次评估中，校准时间段内的样本总和为 2。在第三次评估中，总和为 3，由于此值大于阈值，因此系统会启动重新测试期限的计时器。

重新测试窗口

提醒政策的条件具有重新测试时段，可防止因单个测量结果或预测结果而满足条件。例如，假设某个条件的重新测试时间范围设置为 15 分钟。下面根据其 类型：

• 对于指标阈值条件， 一个时序，那么每隔 15 分钟的每次校准测量结果都会违反 阈值。
• 如果以下平台没有数据到达，则满足指标缺失条件 生成时序，以 15 分钟为间隔。
• 生成的每项预测结果都符合预测条件 期间 15 分钟的时间窗口表示该时序将违反阈值 预测期内的所有展示次数

对于包含一个条件的政策，系统会在满足该条件时创建突发事件并发送通知。在这些事件发生期间， 必须继续满足条件

Google Cloud 控制台

可以使用 Retest window 字段来配置重新测试窗口， 配置提醒触发器步骤。

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 分钟内没有数据，该条件才会满足。对于 响应更快的提醒政策，请将重新测试窗口设置为较小的值。 对于指标阈值条件，为了获得响应最快的提醒政策， 将重新测试窗口设置为零只要有一个对齐的值，就会满足这类条件。

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

具有多个条件的政策

提醒政策最多可包含 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 使用率超过 100ms/s 并持续 1 分钟时，则满足此条件。
• 名为 Excessive utilization 的条件用于监控实例的 CPU 利用率。当任何实例的 CPU 使用率超过 1 分钟的 60% 时，则满足此条件。

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

接下来，假设 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 确定替换值的方式 评估缺失数据，请使用您设置的评估缺失数据字段 条件触发器步骤。在创建 重新测试窗口 设置为 No retest。

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

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

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

Google Cloud 控制台 “缺失数据的评估”字段	摘要	详细信息
缺少数据（为空）	未结突发事件会保持未结状态。 不会打开新的突发事件。	对于满足的条件，条件将继续为 才会出现这种问题如果系统针对此条件创建了突发事件，则该突发事件会保持打开状态。如果突发事件处于打开状态且没有收到任何数据，自动关闭计时器会在至少 15 分钟的延迟后开始计时。如果定时器到期，突发事件将会关闭。 对于不满足的条件，条件将继续不满足 在数据停止到达时满足什么条件。
缺失的数据点被视为违反政策条件的值	未结突发事件会保持未结状态。 可以打开新的突发事件。	对于满足的条件，条件将继续为 才会出现这种问题如果系统针对此条件创建了突发事件，则该突发事件会保持打开状态。如果突发事件处于未结状态，并且在自动关闭时长加上 24 小时内没有收到任何数据，则系统会关闭突发事件。 对于未满足的条件，此设置会导致指标阈值条件的行为类似于 metric-absence condition。如果数据未在重新测试期限指定的时间内到达，则系统会评估该条件是否已满足。对于包含一个条件的提醒政策，满足该条件会导致系统创建突发事件。
缺失的数据点被视为不违反政策条件的值	未结突发事件已关闭。 新的突发事件不会被创建。	如果条件满足，当满足条件时， 数据会停止传送。如果系统针对此条件创建了突发事件，则会关闭该突发事件。 对于未满足的条件，当数据停止传入时，该条件仍不满足。

API

您可以配置 Monitoring 评估 指标阈值条件。 例如，当突发事件未处理且符合预期衡量时 未到达，你希望 Monitoring 离开该事件吗 打开还是立即关闭？同样，当数据停止到达 没有未解决的事件，您是否希望创建事件？最后， 突发事件应在数据停止到达后保持未解决状态吗？

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

• 配置 Monitoring 确定替换值的方式 对于缺失数据，请使用 evaluationMissingData MetricThreshold 结构体的各字段值。 如果 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 发送通知并创建突发事件时

当出现时序时，Cloud Monitoring 会发送通知， 可满足一个条件。通知会发送给 通知渠道。禁止的行为 将通知限制在特定渠道或政策的子集 渠道。

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

您可能会收到多条不同的通知，这些通知分别与 任何一个提醒政策 以下为正确的：

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

• 一项政策包含多个条件。在这种情况下， 则取决于提醒政策多条件 触发器：

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

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

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

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

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

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

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

• 提醒政策已停用。
• 提醒政策已暂停。
• Monitoring 已达到打开次数上限 事件。

停用的提醒政策

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

启用已停用的政策后，Monitoring 会评估 最近的重新测试期内所有条件的值。 最近的重新测试时段可能包含在测试之前、期间和之后收集的数据 该 政策已启用。可以立即满足已停用政策的条件 即使重新测试窗口较大也是如此。

例如，假设您有一个用于监控特定进程的提醒政策，并且您停用了此政策。下周，该进程停止运行，但由于提醒政策已停用，因此您不会收到通知。如果您重新启动该过程并立即启用提醒政策，则： Monitoring 认为该进程未启动， 创建事件

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

已暂停的提醒政策

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

延后提醒政策后，Monitoring 会关闭 与该政策相关的所有未解决突发事件。监控 可以在延后结束后创建新的突发事件如需了解详情，请参阅推迟通知和提醒。

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

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

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

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

受此限制的影响，单个通知渠道最多可接收 同时发送 1,000 条通知。如果您的提醒政策有多个通知渠道，则此限制会分别应用于每个通知渠道。

注意 ：如果针对提醒政策和时序您有未结突发事件 再次超出条件阈值，而 则另一个突发事件未创建Cloud Monitoring 会为提醒政策中的每个时间序列仅维护一个未解决突发事件。

延迟时间

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

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

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

• 重新测试窗口：为条件配置的时间窗口。 只有当条件在整个重新测试过程中都为真时，才会满足条件 窗口。例如，如果重新测试时间范围设置为 5 分钟，则从事件首次发生时起算，通知会至少延迟 5 分钟。

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

后续步骤

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

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

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