使用标签为提醒添加注解

本文档介绍如何通过将用户定义的标签添加到提醒政策来管理通知和突发事件。由于通知中包含用户定义的标签，因此如果您添加指示突发事件严重程度的标签，则通知中包含的信息可帮助您确定需要优先调查哪些提醒。

标签简介

标签是与时序、提醒政策和事件关联的键值对。其中包括指标标签、资源标签和用户定义的标签。指标和资源标签包含有关正在收集的指标或写入指标的资源的具体信息。相比之下，用户定义的标签则是您创建的标签，用来记录您的具体需求。

写入时间序列数据时，数据会附加标签以记录有关该数据的信息。例如，时序上的标签可能标识虚拟机 (VM)、可用区、Google Cloud 项目和设备类型。

您可以将用户标签添加到提醒政策和突发事件：

查看通知中的标签

您可以在突发事件的详情页面、提醒政策的详情页面以及某些通知中查看提醒政策或突发事件的标签：

  • 在电子邮件通知中，您添加到政策的标签列在政策标签部分，而您添加到事件的标签则列在指标标签部分中。

  • 在 PagerDuty、Webhook 和 Pub/Sub 通知中，您添加到提醒政策或突发事件的标签会包含在 JSON 数据中。提醒政策标签列在 JSON 结构的 policy_user_labels 字段中：

    "policy_user_labels": {
  "severity": "critical",
}

    突发事件标签包含在 JSON 结构的 metric 字段中：

    "metric": {
  "type" : "compute.googleapis.com/instance/cpu/utilization"
  "displayName": "CPU Utilization",
  "labels": {
    "instance_name": "some_instance_name",
    "severity": "critical"
  },
}

    如前所述，metric 字段列出了指标类型、指标的显示名称、指标标签以及添加到突发事件的任何用户定义的标签。

示例：使用标签和 MQL 创建动态严重级别

您可以使用 MQL 配置标签，以使其值根据时间序列数据动态更改。例如，您希望突发事件具有一个 Criticality 标签，其值根据受监控的 CPU 利用率指标的值而变化：

fetch gce_instance
| metric 'compute.googleapis.com/instance/cpu/utilization'
| group_by sliding(5m), [value_utilization_mean: mean(value.utilization)]
| map
    add[
      Criticality:
        if(val() >= 90 '%', 'CRITICAL',
          if(val() >= 80 '%', 'WARNING',
            if(val() >= 70 '%', 'INFO', 'GOOD')))
    ]
| condition val() >= 70 '%'

下图说明了使用 MQL 查询的提醒政策如何处理它们监控的时间序列数据：

提醒政策如何处理其受监控的时序的图示。

政策处理程序会处理 CPU 利用率数据，并输出一个时序，以指明何时触发条件。在前面的示例中，当 CPU 利用率至少达到 70% 时，就会触发条件。对于每个输入时序，政策处理程序可以生成以下四个时序之一：

输出时序名称 已触发的条件 说明
“良好” 否 此时序与输入时序的标签相同。它没有严重程度标签。
“CRITIAL” 是 CPU 利用率至少为 90%。输出时序具有与“良好”时序相同的标签，以及值为“CRITIAL”的严重程度标签。
“WARNING” 是 CPU 利用率至少 80%，但低于 90%。输出时序具有与“良好”时序相同的标签，以及值为“WARNING”的严重性标签。
“INFO” 是 CPU 利用率至少 70%，但低于 80%。输出时序具有与“良好”时序相同的标签，此外还有严重性标签值为“INFO”。

政策处理程序生成的时间序列数据是突发事件管理器的输入，用于确定何时创建和关闭突发事件。为了确定何时关闭突发事件，突发事件管理器会使用 duration、evaluationMissingData 和 autoClose 字段的值。

最佳实践

在创建值是动态设置的标签时，若要确保一次最多只发生一个事件，请执行以下操作：

  • 在 MetricThreshold 对象中，替换以下字段的默认值：

    • duration 字段：设置为非零值。
    • evaluationMissingData 字段：进行设置，以便在数据停止到达时关闭突发事件。使用 Cloud Monitoring API 时，请将此字段设置为 EVALUATION_MISSING_DATA_INACTIVE。使用 Google Cloud 控制台时，请将该字段设置为“缺少数据点视为不违反政策条件的值”。

  • 在 AlertStrategy 对象中，将 autoClose 字段设置为其最小值，即 30 分钟。使用 Cloud Monitoring API 时，请将此字段设置为 30m。

如需了解详情，请参阅部分指标数据。

突发事件流程

假设创建提醒政策时 CPU 利用率测量结果低于 70%。以下序列说明了突发事件的创建与关闭方式：

  1. 由于 CPU 利用率测量结果低于 70%，因此政策处理程序会生成“良好”时序，且不会创建任何突发事件。

  2. 接下来，假设 CPU 利用率上升到 93%。政策处理程序会停止生成“良好”时序数据，并开始生成“关键”时序数据。

    突发事件管理器会看到触发条件的新时序，即“CRITIAL”时序，并创建突发事件。通知包含值为 CRITICAL 的严重程度标签。

  3. 假设 CPU 利用率降至 75%。政策处理程序会停止生成“CRITIAL”时序，并开始生成“INFO”时序。

    突发事件管理器会看到触发条件的新时序“INFO”时序，它即会打开一个事件。通知包含值为 INFO 的严重程度标签。

    突发事件管理器会看到“关键”时序没有数据到达，并且该时序有未解决的突发事件。由于政策配置为在数据停止到达时关闭突发事件，因此突发事件管理器会关闭与“CRITIAL”时序关联的突发事件。因此，只有严重级别标签为 INFO 的突发事件仍处于未解决状态。

  4. 最后，假设 CPU 利用率降至 45%。此值小于所有阈值，因此政策处理程序会停止生成“INFO”时序，并开始生成“GOOD”时序。

    突发事件管理器会看到“INFO”时序没有到达数据，并且该时序“事件”未解决。由于政策使用的是推荐的设置，因此突发事件已关闭。

如果您没有为 evaluationMissingData 字段使用建议的值，那么当数据停止到达时，未结突发事件不会立即关闭。因此，您可能会看到同一输入时序有多个未结突发事件。如需了解详情，请参阅部分指标数据。

后续步骤