通过创建警报策略尝试在 GCE VM 处于关闭状态时获取警报。
指标：compute.googleapis.com/instance/uptime
资源：虚拟机实例
并进行了配置，以便在此条件不存在 3 分钟时触发警报。
为了模拟上述行为，我已经停止了 VM，但它没有触发警报，同时数据在警报策略图中不可见
已附加触发器配置
【问题讨论】：
标签： google-cloud-platform google-compute-engine monitoring stackdriver
当虚拟机处于停止状态时，没有任何指标会提供可靠的警报，这些指标是监控代理的 compute.googleapis.com/instance/uptime 或 uptime 或 CPU 利用率指标，直到您使用 MQL - 监控查询创建警报策略语言。
“与 TERMINATED 或 DELETED Google Cloud 资源关联的指标不考虑用于指标缺失政策。这意味着您不能使用指标缺失政策来测试 TERMINATED 或 DELETED Google Cloud VM。” https://cloud.google.com/monitoring/alerts/types-of-conditions#metric-absence
所以按照上面的说法，我们不能对停止的vm使用metic缺席策略——因为它在停止一段时间后进入终止状态。原因是，它仅在实例再次变为运行状态时才计算实例停止时间。
但是，当您使用具有相同指标集的 MQL 配置相同条件时，指标缺失策略可以正常工作。
示例：
不要通过选择 resource & metric 来配置条件，而是转到查询编辑器并键入以下查询以在开发环境 VM 未处于运行状态 3 分钟时获取警报。
fetch gce_instance
| metric 'compute.googleapis.com/instance/uptime'
| filter (metadata.user_labels.env == 'dev')
| group_by 1m, [value_uptime_aggregate: aggregate(value.uptime)]
| every 1m
| absent_for 180s
不确定这是否是错误，但这是我们以传统方式配置警报条件时的限制，我们可以通过利用 MQL 解决此问题。
【讨论】：
您所描述的行为不寻常。
我复制了您的案例，并使用相同的指标compute.googleapis.com/instance/uptime 和相同的设置创建了准确的警报策略。我将所有警报转发到我的电子邮件。
很遗憾，我无法重现此行为。在玩了各种设置（聚合、缺勤时间）后，我收到了提醒电子邮件。
尝试重新设置提醒政策。如果您的目标只是监控虚拟机的状态（响应或不响应），那么您可以使用任何其他指标，例如 cpu usage，当虚拟机关闭（或无响应）时，这些指标将不存在。
最后，您可以在您的 VM 上尝试installing monitoring agent，这将为您提供更多可用指标，从而获得有关机器的更多信息。
查看how to manage alerting policies 可能对您有用的文档。此外，本文档还描述了alerting policies types 以及如何为您的用例选择合适的。
最终尝试创建另一个 VM 并为其设置警报策略。如果这不起作用，您最好的办法是转到Google IssueTracker 并提交新的错误报告，它将由产品团队处理 - 但是这可能需要一些（或很多）时间，具体取决于问题。
【讨论】：