提醒政策问题排查

本页面介绍为何某些提醒政策的行为方式与预期不同，并针对这些情况提供了可能的补救方法。

如需了解可能影响提醒政策的变量（例如，通过选择考量时长），请参阅基于指标的提醒政策的行为。

磁盘利用率政策产生意外突发事件

您创建了一个提醒政策，用于监控系统中磁盘的“已用”容量。此政策会监控指标 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)¹ 定义该条件。当虚拟机 (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 的提醒政策。

¹：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 连接这些条件。您希望在满足所有条件时收到一条通知并创建一个突发事件。但您会收到多个通知，还会发现存在多个突发事件。

当提醒政策包含由逻辑 AND 连接的多个条件时，如果触发政策，那么对于触发了条件的每个时序，该政策都会发送通知然后创建事件。例如，若您的政策包含两个条件，每个条件都监控一个时序，则系统会打开两个突发事件并向您发送两个通知。

您无法将 Cloud 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 角色。

自定义角色无法授予查看突发事件详情所需的权限。

满足条件时不会创建突发事件

您创建了一个具有一个条件的提醒政策。提醒图表显示受监控的数据违反了条件，但您未收到通知，并且未创建突发事件。

如果在提醒政策条件触发后满足以下任何条件，则 Cloud Monitoring 不会创建突发事件。

提醒政策已延后。
提醒政策已停用。
提醒政策已达到其可以同时创建的突发事件数量上限。
提醒政策监控的资源的状态已知为已停用。当资源包含 metadata.system_labels.state 标签且未使用 Monitoring Query Language 编写提醒政策时，Monitoring 可以确定资源的状态。

突发事件详情列表中的项目有误

您会收到一条提醒通知，并且条件摘要会列出创建该提醒的 Google Cloud 项目，也就是说，其中列出了范围项目。但是，您希望突发事件列出存储导致突发事件的时序的 Google Cloud 项目的名称。

在提醒政策的条件中指定的汇总选项决定了通知中引用的 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 通知的问题，请参阅本文档的以下部分：

未收到网络钩子通知
未收到 Pub/Sub 通知

如需收集有关失败原因的信息，请执行以下操作：

在 Google Cloud 控制台的导航面板中，选择 Logging，然后选择 Logs Explorer：
转到 Logs Explorer
选择相应的 Google Cloud 项目。
在日志中查询通知渠道事件：
1. 展开日志名称菜单，然后选择 notification_channel_events。
2. 展开严重程度菜单，然后选择错误。
3. 可选：如要选择自定义时间范围，请使用时间范围选择器。
4. 点击运行查询。
上述步骤会创建以下查询：
```
logName="projects/PROJECT_ID/logs/monitoring.googleapis.com%2Fnotification_channel_events"
severity=ERROR
```
失败信息通常包含在摘要行和 jsonPayload 字段中。

摘要行和 jsonPayload 字段通常包含失败信息。例如，发生网关错误时，摘要行会包含“failed with 502 Bad Gateway”字样。

更改指标定义后没有新数据

您可以更改用户定义的指标的定义，例如，通过修改在基于日志的指标中使用的过滤条件，但提醒政策不会反映您对指标定义所做的更改。

要解决此问题，请通过修改政策的显示名称来强制更新提醒政策。

收不到发送至 Google Chat 的网络钩子通知

您可以在 Cloud Monitoring 中配置 webhook 通知渠道，然后将 webhook 配置为发送到 Google Chat。但您收不到通知，或者收到 400 Bad Request 错误。

如需解决此问题，请在 Cloud Monitoring 中配置 Pub/Sub 通知渠道，然后配置 Cloud Run 服务，将 Pub/Sub 消息转换为 Chat 预期的形式，然后将通知传送给 Google Chat。如需查看该配置的示例，请参阅使用 Cloud Monitoring 和 Cloud Run 创建自定义通知。

未收到网络钩子通知

您可以配置网络钩子通知渠道，并希望在发生突发事件时收到通知。但是，您不会收到任何通知。

专用端点

除非端点处于公开状态，否则您不能将网络钩子用于通知。

如需解决此问题，请参阅 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 通知渠道，但未收到任何提醒通知。

如需改善此情况，请尝试执行以下操作：

确保通知服务账号存在。服务账号被删除后，系统不会发送通知。

如需验证服务账号是否存在，请执行以下操作：
1. 在 Google Cloud 控制台中，选择 IAM，或点击以下按钮：
  转到 IAM
2. 搜索具有以下命名惯例的服务账号：
```
service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
```
  如果此服务账号未列出，请选择包括 Google 提供的角色授权，如以下屏幕截图所示：
如需创建通知服务账号，请执行以下操作：
1. 在 Google Cloud 控制台中，选择 Monitoring，然后选择提醒，或点击以下按钮：
  转到提醒
2. 点击修改通知渠道。
3. 在 Pub/Sub 部分中，点击新增。
  
  已创建 Pub/Sub 渠道对话框显示 Monitoring 创建的服务账号的名称。
4. 点击取消。
5. 授予服务账号发布 Pub/Sub 主题的权限，如为服务账号授权中所述。
确保通知服务账号有权针对感兴趣的 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
```
如需了解如何为通知服务账号授权，请参阅为服务账号授权。