本文档介绍了如何使用校准时间段和重新测试窗口 确定何时满足条件、提醒政策如何将多项 以及提醒政策如何替换缺失的数据点。 还说明了政策的未结突发事件数量上限。 每个事件的通知数量 以及导致通知延迟的原因
此内容不适用于基于日志的提醒政策。如需了解基于日志的提醒政策，请参阅 监控日志。
校准时间段和重新测试窗口
Cloud Monitoring 评估校准时间段和重新测试窗口 在确定是否已满足提醒政策的条件时。
校准时间段
在提醒政策监控时间序列数据之前， 正则化，以便提醒政策定期评估要评估的数据。 正则化过程称为对齐。
校准包含两个步骤：
将时序划分为有规律的时间间隔，也称为分桶 数据。间隔即为校准时间段。
计算校准时间段中各点的单个值。由您选择 该单点的计算方式；您可以对所有值求和，也可以计算 或使用最大值。用于组合数据点的函数 称为校准器。组合的结果是 称为校准后的值。
如需详细了解对齐方式，请参阅 校准：系列内正则化。
例如，当校准时间段为五分钟时，在下午 1:00， 校准时间段包含在中午 12:55 到下午 1:00 之间收到的样本。 在下午 1:01，校准时间段滑动一分钟，并包含在中午 12:56 到下午 1:01 之间收到的样本。
Monitoring 按如下方式配置校准时间段：
Google Cloud 控制台
您可以按如下方式配置校准时间段： 在 Alert conditions（提醒条件）页面上，为以下字段选择一个值：
- 滚动窗口：指定要评估的时间范围。
- 滚动窗口函数：指定数学函数 在数据点窗口上执行的操作。
如需详细了解可用的函数
请参阅 API 参考文档中的 Aligner。部分校准器
这两种函数可将数据
并将其从一种指标种类或类型转换为另一种。有关
请参阅种类、类型和转化。
API
您可以通过设置
aggregations.alignmentPeriod 和 aggregations.perSeriesAligner 字段
在MetricThreshold和
MetricAbsence 结构。
如需详细了解可用的函数
请参阅 API 参考文档中的 Aligner。部分校准器
这两种函数可将数据
并将其从一种指标种类或类型转换为另一种。有关
请参阅种类、类型和转化。
说明校准时间段对提醒中条件的影响
政策时，可以考虑设置符合以下要求的指标阈值条件：
监控具有采样周期的指标
一分钟。假设校准时间段设置为 5 分钟，
校准器设置为 sum。此外，假设条件已满足
当时时序的校准值大于 2 时，
至少三分钟，并且每分钟评估一次条件。
在此示例中，校准时间段为两分钟，重新测试窗口期为
时长为三分钟
下图说明条件的多次顺序评估：
图中的每一行都说明条件的单次评估。系统会显示时间序列数据。校准时间段中的点以
蓝点；较旧的点为黑色。每行显示对齐值和
此值是否大于阈值 2。对于带有
start，则校准后的值计算为 1，即小于阈值。
在下一次评估时，校准时间段内的样本总和为二。
在第三次求时，总和为三，由于该值为
大于阈值，则重新测试窗口的计时器会启动。
重新测试窗口
提醒政策的条件具有重新测试期，这会阻止发生 条件。 例如，假设某个条件的重新测试窗口设置为 15 分钟。下面根据其 类型：
- 对于指标阈值条件， 一个时序，那么每隔 15 分钟的每次校准测量结果都会违反 阈值。
- 如果以下平台没有数据到达，则满足指标缺失条件 生成时序，以 15 分钟为间隔。
- 生成的每项预测结果都符合预测条件 期间 15 分钟的时间窗口表示该时序将违反阈值 预测期内的所有展示次数
对于具有一个条件的政策，系统会创建突发事件并发送通知 在满足该条件时发送。在这些事件发生期间， 必须继续满足条件
Google Cloud 控制台
可以使用 Retest window 字段来配置重新测试窗口， 配置提醒触发器步骤。
API
您可以通过设置名为
在MetricThreshold和duration
MetricAbsence 结构。
上图显示了对指标阈值的三次评估
条件。在
时间 start + 2 minutes，校准后的值大于阈值；
但是，由于重新测试窗口设置为
3 分钟。下图展示了
条件评估：
虽然校准后的值大于
时间 start + 2 minutes，则直到校准值后才满足条件
超过阈值三分钟。该事件发生在
start + 5 minutes.
每次执行测量或预测时，条件都会重置其重新测试窗口 多个尺寸。此行为如下图所示 示例：
示例：此提醒政策包含一个指标阈值条件 指定五分钟的重新测试窗口。
如果 HTTP 响应延迟时间超过两秒，
如果延迟时间超过阈值并持续 5 分钟，
然后创建突发事件并向您的支持团队发送电子邮件。以下序列说明了重新测试期对 条件评估：
- HTTP 延迟时间不到两秒。
- 在接下来连续三分钟的时间内，HTTP 延迟时间更长 超过两秒。
- 在下一次测量中，延迟时间不到两秒，因此 条件会重置重新测试窗口。
在接下来连续五分钟内，HTTP 延迟时间超过了 两秒钟，因此条件得到满足。
由于提醒政策只有一个条件，Monitoring 在满足条件时发送通知。
将重新测试窗口设置为足够长的时间，以最大限度地减少假正例，但 以确保突发事件能够及时得到处理。
设置校准时间段和重新测试窗口的最佳实践
校准时间段决定了使用校准器组合的样本数量：
指标类型的校准时间段的最小值为 该指标类型的采样周期。例如，如果指标类型为 每 300 秒采样一次，则校准时间段应至少为 300 秒但是，如果要合并 5 个样本，请将 校准时间段设置为 5 * 300 秒或 1500 秒。
校准时间段的最大值是提取时间的 24 小时 指标类型的延迟时间例如，如果某项指标的提取延迟时间 为 6 小时，则校准时间段的最大值为 18 小时。
使用重新测试窗口指定提醒的响应能力。例如： 例如，如果您将 指标缺失条件， 则只有在 20 分钟内没有数据才会满足该条件。对于 响应更快的提醒政策，请将重新测试窗口设置为较小的值。 对于指标阈值条件，为了获得响应最快的提醒政策， 将重新测试窗口设置为零单个校准值会导致这些类型的 两个条件。
提醒政策条件按固定频率进行评估。选择 但重新测试窗口不能确定 条件评估频率。
具有多个条件的政策
提醒政策最多可包含 6 个条件。
如果您使用的是 Cloud Monitoring API，或者 您的提醒政策有多个条件，那么您必须指定 创建突发事件如需配置多个条件的合并方式，请执行以下操作之一：
Google Cloud 控制台
您可以在多条件触发器步骤中配置组合器选项。
API
您可以使用combiner
AlertPolicy 结构。
此表列出了 Google Cloud 控制台中的设置， 值以及每项设置的说明：
| Google Cloud 控制台 政策触发值 |
Cloud Monitoring API combiner 值 |
含义 |
|---|---|---|
| 满足任意条件 | OR |
如果任何资源导致满足任何条件，则系统会创建一个突发事件。 |
| 满足所有条件 ，即便每个条件对应不同的 资源 （默认） |
AND |
如果每个 条件，即使 一个不同的资源会使满足这些条件。 |
| 满足所有条件 | AND_WITH_MATCHING_RESOURCE |
如果同一个资源导致满足每个条件，则系统会创建一个突发事件。此设置是最严格的组合选择。 |
在此上下文中，术语符合
表示条件配置的评估结果为 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 分钟。
最初，假设两个条件的计算结果均为 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 分钟最常见冗长 延迟（比重新测试窗口长）可能会导致条件进入 “未知”state.当数据最终到达时，Monitoring 可能已经丢失了一些近期状况的历史记录。 由于一旦数据到达，就再也没有证据表明出现过延迟，因此事后对时间序列数据进行检查可能不会揭示这个问题。
Google Cloud 控制台
您可以配置 Monitoring 评估 指标阈值条件。 例如，当突发事件未处理且符合预期衡量时 未到达，你希望 Monitoring 离开该事件吗 还是要立即关闭？同样，当数据停止到达 没有未解决的事件，您是否希望创建事件？最后， 突发事件应在数据停止到达后保持未解决状态吗？
有两个可配置字段指定 Monitoring 如何 在数据不再到达时评估指标阈值条件：
配置 Monitoring 确定替换值的方式 评估缺失数据，请使用您设置的评估缺失数据字段 条件触发器步骤。在创建 重新测试窗口 设置为 No retest。
重新测试窗口是 Cloud Monitoring API 中名为“时长”的字段。
配置 Monitoring 在关闭前等待的时间 在数据停止到达后处理未结突发事件，请使用 突发事件自动关闭时长字段。您可以在 通知步骤。默认的自动关闭时长为 。
下面介绍了缺失数据字段的不同选项：
| Google Cloud 控制台 “评估缺失数据”字段 |
摘要 | 详细信息 |
|---|---|---|
| 缺少数据为空 | 未结突发事件保持未结状态。 新的突发事件不会被创建。 |
对于满足的条件，条件将继续为 才会出现这种问题如果突发事件符合此条件， 那么该事件就会保持未解决状态当突发事件未处理且无数据时 自动关闭计时器会至少在延迟一刻后启动 15 分钟。如果计时器过期，则事件已关闭。 对于不满足的条件，条件将继续不满足 在数据停止到达时满足什么条件。 |
| 缺失的数据点会被视为违反政策条件的值 | 未结突发事件保持未结状态。 可以创建新突发事件。 |
对于满足的条件，条件将继续为 才会出现这种问题如果突发事件符合此条件， 那么该事件就会保持未解决状态有未结突发事件，但未收到任何数据时 自动关闭时长加 24 小时， 该事件就已关闭 对于不满足的条件，此设置会导致
指标阈值条件的行为类似于 |
| 缺失数据点被视为未违反政策条件的值 | 未结突发事件已关闭。 新的突发事件不会被创建。 |
如果条件满足，那么当 数据会停止传送。如果突发事件符合此条件， 该事件就已关闭 对于不满足的条件，条件将继续不满足 在数据停止到达时满足什么条件。 |
API
您可以配置 Monitoring 评估 指标阈值条件。 例如，当突发事件未处理且符合预期衡量时 未到达，你希望 Monitoring 离开该事件吗 还是要立即关闭？同样，当数据停止到达 没有未解决的事件，您是否希望创建事件？最后， 突发事件应在数据停止到达后保持未解决状态吗？
有两个可配置字段指定 Monitoring 如何 在数据不再到达时评估指标阈值条件：
配置 Monitoring 确定替换值的方式 对于缺失数据，请使用
evaluationMissingDataMetricThreshold结构体的各字段值。 当duration字段为零时，系统会忽略此字段。配置 Monitoring 在关闭前等待的时间 数据停止到达后未结突发事件，请使用
autoClose字段 位于AlertStrategy结构中。
下面介绍了缺失数据字段的不同选项：
APIevaluationMissingData字段 |
摘要 | 详细信息 |
|---|---|---|
EVALUATION_MISSING_DATA_UNSPECIFIED |
未结突发事件保持未结状态。 新的突发事件不会被创建。 |
对于满足的条件，条件将继续为 才会出现这种问题如果突发事件符合此条件， 那么该事件就会保持未解决状态当突发事件未处理且无数据时 自动关闭计时器会至少在延迟一刻后启动 15 分钟。如果计时器过期，则事件已关闭。 对于不满足的条件，条件将继续不满足 在数据停止到达时满足什么条件。 |
EVALUATION_MISSING_DATA_ACTIVE |
未结突发事件保持未结状态。 可以创建新突发事件。 |
对于满足的条件，条件将继续为 才会出现这种问题如果突发事件符合此条件， 那么该事件就会保持未解决状态当突发事件未处理且无数据时 自动关闭时长加上 24 小时， 该事件就已关闭 对于不满足的条件，此设置会导致
指标阈值条件的行为类似于 |
EVALUATION_MISSING_DATA_INACTIVE |
未结突发事件已关闭。 新的突发事件不会被创建。 |
如果条件满足，那么当 数据会停止传送。如果突发事件符合此条件， 该事件就已关闭 对于不满足的条件，条件将继续不满足 在数据停止到达时满足什么条件。 |
您可以通过执行以下任一操作来最大限度地减少因缺少数据而导致的问题：
- 请联系您的第三方云服务提供商，了解如何减少 指标收集延迟时间
- 请在条件中使用较长的重新测试窗口。使用较长的重新测试窗口 但这有一个缺点 响应式。
选择收集延迟时间较短的指标：
- Monitoring 代理指标 - 尤其是当代理在第三方云端的虚拟机实例上运行时。
- 自定义指标，也就是您直接将其数据写入 监控。
- 基于日志的指标（如果日志条目的收集未延迟）。
如需了解详情，请参阅 Monitoring 代理概览、 用户定义的指标概览以及 基于日志的指标。
当 Monitoring 发送通知并创建突发事件时
当出现时序时，Cloud Monitoring 会发送通知， 可满足一个条件。通知会发送给 通知渠道。禁止的行为 将通知仅限于特定渠道或政策的子集 渠道。
如果您配置了重复通知，那么： 系统会向特定的联系人重新发送相同的通知 通知渠道。
您可能会收到多条独特通知，这些通知分别与 任何一个提醒政策 以下为正确的：
一个条件是监控多个时间序列。
一项政策包含多个条件。在这种情况下， 则取决于提醒政策多条件 触发器：
满足所有条件：满足所有条件后， 每个符合某个条件的时序 提醒政策会发送通知并创建突发事件。
您无法将 Cloud Monitoring 配置为仅创建一个突发事件， 当提醒政策包含多个通知时，仅发送一条通知 conditions.
满足任意条件：提醒政策将发送 当时时序导致条件满足时发送通知。
如需了解详情，请参阅具有多个条件的政策。
使用 Cloud Monitoring API 创建的提醒政策也会通知您 当满足条件以及不再满足条件时。 使用 Google Cloud 控制台创建的提醒政策不会发送 并在不再满足条件时发出通知，除非您已启用 行为。
当 Monitoring 未发送通知或未创建突发事件时
在以下情况下，Monitoring 不会创建突发事件 或在满足提醒政策条件时发送通知：
- 提醒政策已停用。
- 提醒政策已延后。
- Monitoring 已达到打开次数上限 事件。
停用的提醒政策
Monitoring 不会发送创建突发事件或发送 已停用提醒政策的通知。不过，Monitoring 继续评估已停用的提醒政策的条件。
启用已停用的政策后，Monitoring 会评估 最近的重新测试期内所有条件的值。 最近的重新测试时段可能包含在测试之前、期间和之后收集的数据 该 政策已启用。可以立即满足已停用政策的条件 即使重新测试窗口较大也是如此。
例如，假设您有一个提醒政策，用于监控特定的 并停用此政策。在接下来的一周， 而且由于提醒政策已停用，系统不会向您发送通知。 如果您重新启动该过程并立即启用提醒政策，则： Monitoring 认为该进程未启动， 创建事件
与已停用的提醒政策相关的事件将保持未解决状态，直到 政策的自动关闭时长到期。
已延后的提醒政策
监控功能不会发送通知，也不会创建突发事件 为已延后的提醒政策。我们建议你延后闹钟 用于阻止提醒政策发送 通知。例如，在执行 对虚拟机进行维护时，您可以创建延后添加到 延后条件：用于监控实例的提醒政策。
延后提醒政策后，Monitoring 会关闭 与该政策相关的所有未结突发事件。监控 可以在延后结束后创建新的突发事件有关详情，请参阅 暂停通知和提醒。
通知和未结突发事件的限制
一项提醒政策可应用于许多资源，而一个问题会影响 所有资源都会导致提醒政策未结突发事件 资源。对于每个导致相应条件的时序，系统都会创建一个突发事件 目标。
为防止系统过载 最多可以同时打开 1,000 个。
例如，假设有一项适用于 2000 Compute Engine 的政策 实例，每个实例都会使提醒发出条件得到满足。 Monitoring 将未结突发事件的数量限制在 1,000。只要满足其余条件 被忽略，直到与该政策相关的一些未结突发事件结束为止。
受此限制的影响，单个通知渠道最多可接收 同时发送 1,000 条通知。如果您的提醒 有多个通知渠道，那么此上限将应用于每个 通知渠道
延迟时间
延迟时间是指从 Monitoring 采样到 以及指标数据点何时以时序数据的形式变得可见。 延迟时间会影响通知的发送时间。例如，如果一个受监控的 最长 180 秒的延迟时间 在 180 秒内，监控不会创建突发事件 提醒政策条件的评估结果为 true。如需了解详情，请参阅 指标数据的延迟时间。
以下事件和设置会导致延迟时间：
指标收集延迟：Monitoring 需要的时间 收集指标值。对于 Google Cloud 值，大多数指标 在收集后的 60 秒内显示；不过，延迟时间取决于 指标提醒政策的计算需要额外的延迟 时长为 60 到 90 秒对于 AWS CloudWatch 指标，可见性延迟 可能需要几分钟的时间对于拨测，此值的平均值为 2 分钟（从重测时间段结束时算起）。
重新测试窗口：为条件配置的时间窗口。 只有当条件在整个重新测试过程中都为真时，才会满足条件 窗口。例如，将重新测试窗口设置为 5 分钟会导致 从设备收到事件响应开始算起，通知至少延迟五分钟。 事件最先发生。
通知到达时间：通知渠道，例如电子邮件 和短信时，可能会遇到网络延迟或其他延迟（与 传送内容），有时会将近几分钟。在某些渠道上（例如短信和 Slack），无法保证消息一定会成功传送。
后续步骤
如需了解如何创建提醒政策，请参阅以下内容 文档：
如需了解各类提醒政策，请参阅示例政策。