本页面介绍为何某些提醒政策的行为方式与预期不同，并针对这些情况提供了可能的补救方法。
如需了解可能影响提醒政策的变量（根据时长窗口的选择），请参阅基于指标的提醒政策的行为。
指标标签的变量为 null
您将创建提醒政策，并将指标标签的变量添加到文档部分。您希望通知将显示该变量的值；不过，该值设置为 null。
如需解决此问题，请尝试以下操作：
确保提醒政策的聚合设置保留要显示的标签。
例如，假设您创建了一个提醒政策，用来监控虚拟机实例写入的磁盘字节数。您希望文档中列出引起通知的设备，因此向文档字段中添加以下代码：
device: ${metric.label.device}。您还必须确保聚合设置保留
device标签的值。您可以通过将聚合函数设置为none或确保分组选择包含device来保留此标签。验证变量的语法和适用性。如需了解语法信息，请参阅使用用户定义的文档为提醒添加注解。
例如，只有基于日志的提醒支持变量
log.extracted_label.KEY。当提醒政策监控某个指标（即使是基于日志的指标）时，此变量始终呈现为null。
磁盘利用率政策产生意外突发事件
您创建了一个提醒政策，用于监控系统中磁盘的“已用”容量。此政策会监控指标 agent.googleapis.com/disk/percent_used。您预期仅在任何物理磁盘的利用率超过您在条件中设置的阈值时收到通知。但是，此政策会在每个物理磁盘的磁盘利用率低于阈值时创建突发事件。
这些政策的意外突发事件的已知原因是此类条件不限于监控物理磁盘。这些政策会改为监控所有磁盘，包括环回设备等虚拟磁盘。如果构建了一个虚拟磁盘，使其利用率达到 100%，则会导致创建政策的突发事件。
例如，请考虑 Linux df 命令的下列输出，其中显示系统所装载的文件系统上的磁盘空间：
$ df /dev/root 9983232 2337708 7629140 24% / devtmpfs 2524080 0 2524080 0% /dev tmpfs 2528080 0 2528080 0% /dev/shm ... /dev/sda15 106858 3934 102924 4% /boot/efi /dev/loop0 56704 56704 0 100% /snap/core18/1885 /dev/loop1 129536 129536 0 100% /snap/google-cloud-sdk/150 ...
对于此系统，应配置磁盘利用率提醒政策，以过滤掉环回设备 /dev/loop0 和 /dev/loop1 的时序。例如，您可以添加过滤条件 device !=~ ^/dev/loop.*，以排除 device 标签与正则表达式 ^/dev/loop.* 不匹配的所有时序。
正常运行时间政策不产生预期的提醒
您希望在虚拟机 (VM) 重新启动或关停时收到通知，因此您要创建监控指标 compute.googleapis.com/instance/uptime 的提醒政策。您可以创建并配置条件，以便在没有指标数据时生成突发事件。您不能使用 Monitoring Query Language (MQL)1 定义该条件。当虚拟机 (VM) 重新启动或关停时，系统不会通知您。
此提醒政策仅监控处于 RUNNING 状态的 Compute Engine 虚拟机实例的时序。对于任何其他状态（例如 STOPPED 或 DELETED）的虚拟机，系统会在评估条件之前过滤掉其时序。鉴于此行为，您不能使用带有指标缺失提醒条件的提醒政策来确定虚拟机实例是否正在运行。如需了解虚拟机实例状态，请参阅虚拟机实例生命周期。
如需解决此问题，请创建提醒政策以监控拨测。对于专用端点，请使用专用拨测。
除提醒拨测之外，您还可以选择使用提醒政策来监控缺失数据。我们强烈建议您在拨测时发出提醒，而不是在缺少数据上发出提醒：如果 Monitoring 数据的可用性出现暂时性问题，缺失提醒可能会生成误报。
但是，如果无法使用拨测，您可以使用 MQL 创建提醒政策，以通知您虚拟机已关闭。MQL 定义的条件不会根据虚拟机实例的状态预先过滤时间序列数据。由于 MQL 不会按虚拟机状态过滤数据，因此您可以使用它来检测已关停的虚拟机的数据缺失。
请考虑监控 compute.googleapis.com/instance/cpu/utilization 指标的以下 MQL 条件：
fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
|absent_for 3m
如果此条件监控的虚拟机关闭，三分钟后，将生成一个突发事件并发送通知。absent_for 值必须至少为三分钟。
如需详细了解 MQL，请参阅使用 MQL 的提醒政策。
1：MQL 是一种具有表现力的文本型语言，可与 Cloud Monitoring API 调用和 Google Cloud 控制台搭配使用。如需在使用 Google Cloud 控制台时通过 MQL 配置条件，您必须使用代码编辑器。
请求数政策不会创建预期提醒
您想监控已完成的请求数量。您创建了一个提醒政策，该政策会监控 serviceruntime.googleapis.com/api/request_count 指标，但当请求数超过您配置的阈值时，您不会收到通知。
请求计数指标的最长校准时间段为 7 小时 30 分钟。
如需解决此问题，请检查提醒政策中的校准时间段的值。如果值长于此指标的最大值，请缩短校准时间段，使其不超过 7 小时 30 分钟。
异常突发事件的常见原因
您创建了一个提醒政策，该政策似乎过早创建或错误地创建了突发事件。
由于多种原因，您可能会收到看似不正确的事件通知：
如果数据中存在缺口，尤其对于存在指标缺失或“小于”阈值条件的提醒政策，则可能创建看似异常的突发事件。有时突发事件不会显示数据缺口，有时则会自动纠正数据缺口：
例如，在图表中，由于缺失数据的值已经过插值，因此可能不会出现缺口。即使缺少几分钟的数据，图表也会连接缺失的点，以获得视觉上的连续性。提醒政策中的此类缺口可能足以让提醒政策创建突发事件。
基于日志的指标中的点可能会延迟到达并回填（过去最长 10 分钟内）。回填行为可以有效地纠正缺口；当数据最终到达时，会填补缺口。因此，基于日志的指标中一个再也看不见的缺口可能导致提醒政策创建突发事件。
指标缺失和“小于”阈值条件会实时评估，查询延迟时间很短。在评估条件到相应突发事件在 Monitoring 中可见这段时间内，条件的状态可能会发生变化。
配置为针对单个测量创建突发事件的条件可能会导致看似过早或不正确的突发事件。为了避免这种情况，请将条件的持续时间字段设置为大于指标的采样率的两倍，确保在创建突发事件之前需要进行多次测量。
例如，如果指标每 60 秒采样一次，请将时长设置为至少 3 分钟。如果您将时长字段设置为最近的值（或相当于 0 秒），则单个测量结果可能会导致创建突发事件。
修改提醒政策的条件时，更改可能需要几分钟才能在提醒政策基础架构中传播。在此期间，您可能会收到满足原来的提醒政策条件的突发事件通知。
时间序列数据到达时，数据可能需要一分钟才能传播到整个提醒基础架构。当校准时间段设置为一分钟或最近的样本时，传播延迟时间可能会使提醒政策看起来未正确触发。为减少出现这种情况的可能性，请使用至少五分钟的校准时间段。
数据停止到达时，突发事件未关闭
您可以按照部分指标数据中的指南操作，并配置提醒政策，以便在数据停止到达时关闭突发事件。在某些情况下，数据停止传送，但未结突发事件不会自动关闭。
如果提醒政策监控的底层资源包含 metadata.system_labels.state 标签，并且该政策未使用 Monitoring Query Language 编写，则 Monitoring 可以确定资源的状态。如果已知某个资源的状态已停用，则 Monitoring 不会在数据停止到达时自动关闭突发事件。不过，您可以手动关闭这些突发事件。
多条件政策创建多个通知
您创建了一个包含多个条件的提醒政策，并使用逻辑 AND 连接这些条件。您希望在满足所有条件时收到一条通知并创建一个突发事件。但您会收到多个通知，还会发现存在多个突发事件。
Monitoring 会发送通知，并为满足条件的每个时序创建一个突发事件。因此，当您的提醒政策包含多个条件时，对于每个时序，您可能会收到一个满足联接条件的通知和突发事件。
例如，您有一个包含两个条件的提醒政策，其中每个条件监控 3 个时序。仅当同时满足这两个条件时，政策才会发送通知。当满足政策条件时，您可能会收到 2 个（每个条件满足一个时序）到 6 个（每个条件满足所有时序）的通知和突发事件。
您不能将 Monitoring 配置为创建单个突发事件并发送单个通知。
如需了解详情，请参阅每次事件的通知数。
由于权限错误，导致无法查看突发事件详情
前往 Google Cloud 控制台中的突发事件页面，然后选择要查看的突发事件。您应能打开详情页面。但是，详情页面无法打开，并显示“权限遭拒”的消息。
如需查看除指标数据以外的所有突发事件详情，请确保您拥有 Monitoring Cloud Console Incident Viewer (roles/monitoring.cloudConsoleIncidentViewer) 和 Stackdriver Accounts Viewer (roles/stackdriver.accounts.viewer) 的 Identity and Access Management (IAM) 角色。
如需查看所有突发事件详情（包括指标数据），以及确认或关闭突发事件，请确保您拥有 Monitoring Viewer (roles/monitoring.viewer) 和 Monitoring Cloud Console Incident Editor (roles/monitoring.cloudConsoleIncidentEditor) 的 IAM 角色。
自定义角色无法授予查看突发事件详情所需的权限。
满足条件时不会创建突发事件
您创建了一个包含一项条件的提醒政策。提醒图表显示受监控的数据违反了条件，但您并未收到通知，并且未创建突发事件。
如果在满足提醒政策条件后满足以下任何条件，则 Monitoring 不会打开突发事件。
- 提醒政策处于延后状态。
- 提醒政策已停用。
- 提醒政策已达到其可同时创建的突发事件数量上限。
提醒政策监控的资源的状态已知为已停用。当资源包含
metadata.system_labels.state标签以及未使用 Monitoring Query Language 编写提醒政策时，Monitoring 可以确定资源的状态。
突发事件详情列表中的项目有误
您会收到通知，并且条件摘要会列出创建突发事件的 Google Cloud 项目，即限定范围项目。但是，您希望突发事件列出 Google Cloud 项目的名称，该项目存储了导致 Monitoring 创建突发事件的时序。
在提醒政策的条件中指定的聚合选项决定了通知中引用的 Google Cloud 项目：
如果汇总选项消除了用于存储项目 ID 的标签，突发事件信息将列出限定范围的项目。例如，如果您仅按地区对数据进行分组，则在分组后，系统会移除存储项目 ID 的标签。
如果聚合选项保留用于存储项目 ID 的标签，则突发事件通知会包含存储导致突发事件的时序的 Google Cloud 项目的名称。如需保留项目 ID 标签，请在分组字段中添加标签
project_id，或者不要对时序进行分组。
无法手动结束突发事件
您收到系统突发事件通知。转到突发事件详情页面，然后点击结束突发事件。突发事件应能结束；但是您收到以下错误消息：
Unable to close incident with active conditions.
只有在最近的提醒期内没有收到任何观察结果时，您才能结束突发事件。提醒期（通常默认为 5 分钟）作为提醒政策条件的一部分进行定义，并且可以对其进行配置。上一条错误消息表明在提醒期内收到数据。
如果突发事件因内部错误而无法关闭，则会发生以下错误：
Unable to close incident. Please try again in a few minutes.
当您看到上一条错误消息时，可以重试关闭操作，或者让 Monitoring 自动关闭突发事件。
如需了解详情，请参阅管理突发事件。
未收到通知
您可以配置通知渠道，并希望在发生突发事件时收到通知。但是，您不会收到任何通知。
如需了解如何解决 webhook 和 Pub/Sub 通知问题，请参阅本文档的以下部分：
如需收集有关失败原因的信息，请执行以下操作：
-
在 Google Cloud 控制台的导航面板中，选择 Logging，然后选择 Logs Explorer：
- 选择相应的 Google Cloud 项目。
在日志中查询通知渠道事件：
- 展开日志名称菜单，然后选择 notification_channel_events。
- 展开严重程度菜单，然后选择错误。
- 可选：要选择自定义时间范围，请使用时间范围选择器。
- 点击运行查询。
上述步骤会创建以下查询：
logName="projects/PROJECT_ID/logs/monitoring.googleapis.com%2Fnotification_channel_events" severity=ERROR失败信息通常包含在摘要行和
jsonPayload字段中。摘要行和
jsonPayload字段通常包含失败信息。例如，当发生网关错误时，摘要行会包含“failed with 502 Bad Gateway”。
更改指标定义后没有新数据
您可以更改用户定义的指标的定义，例如，通过修改在基于日志的指标中使用的过滤条件，但提醒政策不会反映您对指标定义所做的更改。
如需解决此问题，请通过修改政策的显示名称来强制更新提醒政策。
收不到发送到 Google Chat 的网络钩子通知
您可以在 Monitoring 中配置网络钩子通知渠道，然后将该网络钩子配置为发送到 Google Chat。但是，您收不到通知，或者收到 400 Bad Request 错误。
如需解决此问题，请在 Monitoring 中配置 Pub/Sub 通知渠道，然后配置 Cloud Run 服务以将 Pub/Sub 消息转换为 Chat 预期的形式，然后将通知传送到 Google Chat。如需查看该配置的示例，请参阅使用 Cloud Monitoring 和 Cloud Run 创建自定义通知。
未收到 Webhook 通知
您可以配置网络钩子通知渠道，并希望在发生突发事件时收到通知。但是，您不会收到任何通知。
专用端点
除非端点处于公开状态，否则您不能将网络钩子用于通知。
如需解决此问题，请参阅 Pub/Sub 通知以及针对该通知主题的拉取订阅。
配置 Pub/Sub 通知渠道时，突发事件通知将发送到具有 Identity and Access Management 控制的 Pub/Sub 队列。任何可以查询或监听 Pub/Sub 主题的服务都可以使用这些通知。例如，在 App Engine、Cloud Run 或 Compute Engine 虚拟机上运行的应用可以使用这些通知。
如果您使用拉取订阅，系统会向 Google 发送请求，等待消息到达。这些订阅需要访问 Google，但不需要防火墙或入站访问规则。
公共端点
如需确定传送失败的原因，请检查您的 Cloud Logging 日志条目以获取失败信息。
例如，您可以使用日志浏览器搜索通知渠道资源的日志条目，过滤条件如下所示：
resource.type="stackdriver_notification_channel"
未收到 Pub/Sub 通知
您配置了 Pub/Sub 通知渠道，但您收不到任何通知。
如需改善此情况，请尝试执行以下操作：
确保通知服务账号存在。服务账号被删除后，系统不会发送通知。
如需验证服务账号是否存在，请执行以下操作：
-
在 Google Cloud 控制台的导航面板中，选择 IAM：
搜索具有以下命名惯例的服务帐号：
service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
如果未列出此服务帐号，请选择包括 Google 提供的角色授权。
如果通知服务帐号不存在，您必须开始创建 Pub/Sub 通知渠道，以便 Monitoring 创建服务帐号：
-
确保通知服务账号有权针对感兴趣的 Pub/Sub 主题发送通知。
如需查看服务帐号的权限，您可以使用 Google Cloud 控制台或 Google Cloud CLI 命令：
- Google Cloud 控制台中的 IAM 页面列出了每个服务帐号的角色。
- Google Cloud 控制台中的 Pub/Sub 主题页面列出了每个主题。选择主题时，权限标签页列出了授予服务账号的角色。
如需列出所有服务账号及其角色，请运行以下 Google Cloud CLI 命令：
gcloud projects get-iam-policy PROJECT_ID以下是此命令的部分响应：
serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com role: roles/monitoring.notificationServiceAgent - members: [...] role: roles/owner - members: - serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com role: roles/pubsub.publisher命令响应仅包含角色，不包括按主题进行授权。
如需列出特定主题的 IAM 绑定，请运行以下命令：
gcloud pubsub topics get-iam-policy TOPIC以下是此命令的示例响应：
bindings: - members: - serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com role: roles/pubsub.publisher etag: BwXPRb5WDPI= version: 1
如需了解如何为通知服务账号授权，请参阅为服务账号授权。