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

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

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

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

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

校准时间段

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

校准包含两个步骤：

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

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

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

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

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

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

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

重新测试窗口

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

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

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

上图说明了指标阈值条件的三次评估。在时间 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 控制台中的设置、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 使用率超过阈值一分钟，条件 符合 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 可能已经丢失了一些近期状况的历史记录。 由于一旦数据到达，就再也没有证据表明出现过延迟，因此事后对时间序列数据进行检查可能不会揭示这个问题。

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

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

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

  • 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 条通知。如果您的提醒政策有多个通知渠道，则此限制会分别应用于每个通知渠道。

延迟时间

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

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

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

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

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

后续步骤

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

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

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