提醒政策问题排查

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

如需了解可通过选择时长等方式影响提醒政策的变量,请参阅提醒行为

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

您创建了一个提醒政策,用于监控系统中磁盘的“已用”容量。此政策会监控指标 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 的时间序列。

正常运行时间政策不产生预期的提醒

您希望在虚拟机 (VM) 重新启动或关停时收到通知,因此您要创建监控指标 compute.googleapis.com/instance/uptime 的提醒政策。您可以创建并配置条件,以便在没有指标数据时生成突发事件。您不能使用 Monitoring Query Language (MQL)1 定义该条件。当虚拟机 (VM) 重新启动或关停时,系统不会通知您。

此提醒政策仅监控处于 RUNNING 状态的 Compute Engine 虚拟机实例的时间序列。对于任何其他状态(例如 STOPPEDDELETED)的虚拟机,系统会在评估条件之前过滤掉其时序。鉴于此行为,您不能使用带有指标缺失提醒条件的提醒政策来确定虚拟机实例是否正在运行。如需了解虚拟机实例状态,请参阅虚拟机实例生命周期

如需解决此问题,请创建提醒政策以监控拨测。如需创建拨测,您的虚拟机必须具有外部 IP 地址。

如果您的虚拟机没有外部 IP 地址,则可以使用 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 Console 中使用。如需在使用 Cloud Console 时通过 MQL 配置条件,则必须选择查询编辑器

异常突发事件的常见原因

您创建了一个提醒政策,该政策似乎过早创建或错误地创建了突发事件。

如果数据中存在缺口,尤其对于存在指标缺失或“小于”阈值条件的提醒政策,则可能创建看似异常的突发事件。确定数据中是否存在缺口可能不容易。有时候缺口很模糊,而有时候它会被自动纠正。

  • 例如,在图表中,数据缺口可能会被遮盖,因为缺失数据的值会被插值。即使缺少几分钟的数据,图表也会连接缺失的点,以获得视觉上的连续性。提醒政策中的此类缺口可能足以让提醒政策创建突发事件。

  • 如果基于日志的指标中的点出现延迟,系统可能会对其进行回填(针对过去最长 10 分钟的数据点进行回填)。回填行为可以有效地纠正缺口;当数据最终到达时,会填补缺口。因此,基于日志的指标中一个再也看不见的缺口可能已经导致了提醒政策创建突发事件。

指标缺失和“小于”阈值条件会实时评估,查询延迟时间很短。在评估条件到相应突发事件在 Monitoring 中可见这段时间内,条件的状态可能会发生变化。

要确保在创建突发事件之前需要进行多次测量,请确保条件的时长字段超过指标采样率的两倍。例如,如果指标每 60 秒采样一次,请将时长设置为至少 3 分钟。如果您将时长字段设置为最近的值(或相当于 0 秒),则单个测量结果可能会导致创建突发事件。

多条件政策创建多个通知

您创建了一个包含多个条件的提醒政策,并使用逻辑 AND 连接这些条件。您希望在满足所有条件时收到一条通知并创建一个突发事件。但您会收到多个通知,还会发现存在多个突发事件。

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

您无法将 Cloud Monitoring 配置为创建单个突发事件并发送单个通知。

如需了解详情,请参阅每次事件的通知数

由于权限错误,导致无法查看突发事件详情

导航到 Google Cloud Console 中的突发事件页面,然后选择要查看的突发事件。您应能打开详情页面。但是,详情页面无法打开,并显示“权限遭拒”的消息。

如需解决此问题,请确保您的 Identity and Access Management (IAM) 角色为 roles/monitoring.viewer 或包含该角色所有权限的角色。例如,roles/monitoring.editorroles/monitoring.admin 角色包含 Viewer 角色的所有权限。

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

无法手动结束突发事件

您收到系统突发事件通知。转到突发事件详情页面,然后点击结束突发事件。突发事件应能结束;但是您收到以下错误消息:

Unable to close incident with active conditions.

只有在最近的提醒期内没有收到任何观察结果时,您才能结束突发事件。提醒期(通常默认为 5 分钟)作为提醒政策条件的一部分进行定义,并且可以对其进行配置。上一条错误消息表明在提醒期内收到数据。

如果突发事件因内部错误而无法关闭,则会发生以下错误:

Unable to close incident. Please try again in a few minutes.

当您看到上一条错误消息时,可以重试关闭操作,或者让 Monitoring 自动关闭突发事件。

如需了解详情,请参阅管理突发事件

网络钩子通知失败

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

专用端点

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

如需解决此问题,请参阅 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"