本页面包含有关使用 Monitoring Query Language (MQL) 条件的提醒政策的最佳实践索引。您可以将此处收集的信息用作在根据 MQL 的条件配置提醒政策时应注意的事项的快速参考。
本页面未介绍有关如何在提醒政策中使用 MQL 查询的基础知识。如果您是新用户，请参阅使用 MQL 的提醒政策。
针对提醒政策中 MQL 查询的建议操作
提醒政策评估涉及多项内部服务。由于这些服务与 MQL 交互的方式，我们强烈建议您使用某些 MQL 操作，而不是其他操作。例如，如果您使用 delta 而不是 delta_gauge，则可能会在错误的时间触发提醒。
下表显示了要避免的操作列表以及建议改用的操作。
| 应避免的做法 | 推荐 |
|---|---|
adjacent_rate |
rate |
adjacent_delta |
delta_gauge |
delta |
delta_gauge |
window |
sliding |
将 every 30s 语句与提醒政策结合使用
提醒政策每 30 秒评估一次其条件。此时间范围称为输出时段。
我们建议您的条件中包含明确的 every 30s 操作，作为此时间段的视觉提醒。
例如，以下提醒政策 MQL 查询包含显式 every 30s 语句：
fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count | group_by sliding(1h) | every 30s
如果您使用对 every 操作使用不同的值的 MQL 查询来保存提醒政策，则当提醒政策处于有效状态时，Cloud Monitoring 仍会使用 30 秒的值。例如，包含以下查询的提醒政策仍然具有 30 秒的输出时段：
fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count | group_by sliding(1h) | every 90s
提高查询效率
在处理大量数据时，查询运行缓慢。为了提高查询效率，您可以尝试减少查询处理的数据量。以下部分提供了多种方法来减少查询评估的数据量。
在查询的前面部分添加过滤条件
如果您在查询中提前设置了过滤条件，那么这些过滤条件可以在查询对数据执行操作之前滤除不必要的数据。例如，请考虑以下查询：
fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count | group_by [resource.zone], .sum | filter zone = 'us-west1-b' | condition val() > 5'GBy'
如果将 filter 操作移至 group_by 操作之前，查询运行速度可能会更快：
fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count | filter zone = 'us-west1-b' | group_by [resource.zone], .sum | condition val() > 5'GBy'
缩小查询对齐窗口
当查询使用 align 操作时，校准时间段越短表示 Cloud Monitoring 针对时序中的每个点评估的时间范围越短。因此，您可以尝试通过减少 align 操作的值来提高查询效率。例如，以下查询的校准回溯期时长为 2 小时：
fetch gce_instance :: compute.googleapis.com/instance/disk/read_bytes_count | group_by window(1h), .sum | align next_older(2h) | every 30s | condition val() > 2'GBy'
不过，如果您只需查看 1 小时窗口的数据，则可以将校准窗口缩短为 1 小时：
fetch gce_instance :: compute.googleapis.com/instance/disk/read_bytes_count | group_by window(1h), .sum | align next_older(1h) | every 30s | condition val() > 2'GBy'
如需了解详情，请参阅对齐。
缩短提醒政策的持续时间
提醒政策持续时间窗口表示在发送提醒之前每个测量必须违反条件的时间段。如果您在不增加查询校准窗口的情况下缩短提醒政策的持续时间，则 Cloud Monitoring 需要评估提醒政策条件的数据点就会更少。
如需了解详情，请参阅考量时长。
为 null 元数据分配默认值
如果元数据值为 null，则您的查询可能会生成意外结果。您可以使用 or_else 函数将默认值分配给原本具有 null 值的元数据，以避免意外结果。
例如，您运行的查询将所有数据汇总到一起：
fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count | group_by [], 24h, sum(egress_bytes_count) | condition val() > 10'MBy'
查询生成的结果为 10MBy。接下来，您将运行查询，以验证 10 MBy 大小在各节点可用区之间是如何分布的：
fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count | group_by [metadata.system.node_zone], 24h, sum(egress_bytes_count) | condition val() > 10'MBy'
分布查询会返回以下结果：
node_zone |
egress_byte_count |
|---|---|
| us-central1-f | 7.3 MB |
| us-west1-b | 2.5 MB |
这些结果显示总计 9.8MBy，而不是预期的 10MBy。如果其中一个汇总的元数据标签为 null 值，则可能会发生这种差异，例如在以下数据集中：
| 值 | 元数据值 |
|---|---|
| 7.3 MB | us-central1-f |
| 2.5 MB | us-west1-b |
| 0.2 MB |
为避免 null 元数据出现问题，您可以将元数据引用封装在 or_else 操作中，这让您可以在元数据列没有值时指定默认值。例如，以下查询使用 or_else 为没有值的所有元数据列设置元数据值 no zone：
fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count | group_by [or_else(metadata.system.node_zone, 'no zone')], 24h, sum(egress_bytes_count) | condition val() > 10'MBy'
这一新查询会生成以下结果，结果的总和为 10 MBy：
node_zone |
egress_byte_count |
|---|---|
| us-central1-f | 7.3 MB |
| us-west1-b | 2.5 MB |
| 无区域 | 0.2 MB |