使用标签为提醒添加注解

本文档介绍了如何通过向提醒政策添加用户定义的标签来管理通知和突发事件。由于通知中包含用户定义的标签，因此如果您添加可指示突发事件严重程度的标签，那么通知会包含有助于您为提醒确定调查优先级的信息。

标签简介

标签是与时序、提醒政策和突发事件相关联的键值对。有指标标签、资源标签和用户定义的标签。指标和资源标签包含有关所收集指标或写入指标的资源的具体信息。相比之下，用户定义的标签是指您创建的以及根据您的需求记录信息的标签。

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

您可以为提醒政策和事件添加用户标签：

查看通知中的标签

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

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

  • 在 PagerDuty、网络钩子和 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 字段列出了指标类型、指标的显示名称、指标标签和添加到突发事件的任何用户定义的标签。

示例：使用标签报告严重级别

本部分提供了两个示例，说明了如何使用标签在通知中包含严重程度信息。

假设您希望在虚拟机的 CPU 利用率超过阈值时收到通知，并且您希望通知包含以下严重程度信息：

  • critical：CPU 利用率至少为 90%。
  • warning：CPU 利用率至少为 80% 但低于 90%。
  • info：CPU 利用率至少为 70% 但低于 80%。

创建静态严重级别

您将创建三个提醒政策。对于每项政策，您可以将其条件配置为在 CPU 利用率高于阈值时触发。此外，对于每项政策，您都会添加一个严重程度标签，其值决定了政策的阈值。

您将创建三项政策，因为提醒政策的标签具有静态值。因此，您必须针对标签的每个值创建一个政策。

  • 政策 A：此条件会在 CPU 利用率至少达到 90% 时触发。 severity 标签设置为 critical：

    "userLabels": {
   "severity": "critical",
}

  • 政策 B：在 CPU 利用率至少达到 80% 时触发条件。 severity 标签设置为 warning：

    "userLabels": {
   "severity": "warning",
}

  • 政策 C：在 CPU 利用率至少达到 70% 时触发条件。 severity 标签设置为 info：

    "userLabels": {
   "severity": "info",
}

在此示例中，当 CPU 利用率超过 90% 时，您会收到三条通知，每项政策一条。您可以使用 severity 标签的值来确定要先调查的突发事件。

当 CPU 利用率低于 70% 时，Monitoring 会自动关闭所有未结突发事件。如需了解突发事件关闭情况，请参阅关闭突发事件。

使用 MQL 创建动态严重级别

为突发事件创建标签时，您可以使用一项政策，并由数据的值决定通知中包含的标签的值。也就是说，您无需为标签可以具有的每个值创建不同的提醒政策。

例如，请考虑以下 MQL 查询，它添加了一个 Severity 标签：

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

下图说明了 MQL 提醒政策如何处理他们监控的时序数据：

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

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

输出时序名称 所触发的条件 说明
“良好” 否 此时序的标签与输入时序相同。没有严重程度标签。
“严重” 是 CPU 利用率至少为 90%。输出时序具有与“良好”时序相同的标签，并且严重程度标签为“CRITICAL”。
“警告” 是 CPU 利用率至少为 80% 但小于 90%。输出时序具有与“良好”时序相同的标签，并且严重程度标签为“WARNING”。
“信息” 是 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%。政策处理程序停止生成“良好”时序数据，并开始生成“关键”时序的数据。

    突发事件管理器会看到触发条件的新时序“关键”时序，并会创建一个突发事件。通知中会包含严重级别标签，值为 CRITICAL。

  3. 假设 CPU 利用率为 75%。政策处理程序停止生成“关键”时序，开始生成“信息”时序。

    突发事件管理器会看到触发条件的新时间序列（即“信息”时序），并会打开突发事件。通知中会包含严重级别标签，值为 INFO。

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

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

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

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

后续步骤