本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 通知策略
<a name="v10-alerting-explore-notifications-policies-details"></a>

****  
本文档主题专为支持 **Grafana 10.x 版本**的 Grafana 工作区而设计。  
对于支持 Grafana 9.x 版本的 Grafana 工作区，请参阅[使用 Grafana 版本 9](using-grafana-v9.md)。  
对于支持 Grafana 8.x 版本的 Grafana 工作区，请参阅[使用 Grafana 版本 8](using-grafana-v8.md)。

通知策略为您提供了一种灵活的方式，可将警报路由给不同的接收者。您可以使用标签匹配程序，修改警报通知的发送方式，而无需更新每一条警报规则。

在本节中，您将详细了解通知策略的工作原理和结构，以便您可以充分利用通知策略的设置。

## 策略树
<a name="v10-alerting-explore-notifications-policy-tree"></a>

通知策略*不是*列表，而是根据树形结构来构建的。这意味着每个策略都可以有子策略，以此类推。通知策略树的根称为**默认通知策略**。

每条策略都由一组标签匹配程序（0 个或多个）组成，这些标签匹配程序指定了需要或不需要处理的标签。

有关匹配标签的更多信息，请参阅 [标签匹配的工作原理](v10-alerting-overview-labels-matching.md)。

**注意**  
如果没有为通知策略配置任何标签匹配程序，通知策略将匹配*所有*警报实例。除非您在通知策略上启用了**继续匹配同级策略**，否则这可能会阻止对子策略的评估。

## 路由
<a name="v10-alerting-explore-notifications-routing"></a>

要确定哪个通知策略将处理哪些警报实例，必须先查看现有的通知策略集，从默认通知策略开始。

如果除默认策略外没有配置任何策略，则默认策略将处理警报实例。

如果定义了默认策略以外的策略，则将按照通知策略的显示顺序对其进行评估。

如果通知策略的标签匹配程序与警报实例的标签匹配，则该策略将下降到其子策略，如果有匹配项，则将继续查找可能具有标签匹配程序的任何子策略，以进一步缩小标签集，依次类推，直到找不到更多子策略。

如果通知策略中未定义子策略，或者子策略中没有任何与警报实例标签匹配的标签匹配程序，则使用父通知策略。

一旦找到匹配策略，系统就不会继续寻找其他匹配策略。如果要继续查找可能匹配的其他策略，请在特定策略上启用**继续匹配同级策略**。

最后，如果未选择任何通知策略，则使用默认通知策略。

### 路由示例
<a name="v10-alerting-explore-notifications-routing-example"></a>

下面是一个相对简单的通知策略树和一些警报实例的示例。

![\[图中以树结构形式显示了一组通知策略，以及一组具有不同标签，可匹配策略的警报实例。\]](http://docs.aws.amazon.com/zh_cn/grafana/latest/userguide/images/notification-routing.png)


以下是如何选择这些策略的明细：

**卡在里 CrashLoop面的 Pod** 没有`severity`标签，因此其子策略都不匹配。其具有 `team=operations` 标签，因此会匹配第一个策略。

由于我们已找到匹配项，并且没有为该策略配置**继续匹配同级策略**，因此未评估 `team=security` 策略。

**Disk Usage - 80%** 具有 `team` 和 `severity` 标签，匹配运营团队的子策略。

**Unauthorized log entry** 具有 `team` 标签，但不匹配第一个策略（`team=operations`），因为值不同，所以会继续搜索并匹配 `team=security` 策略。由于没有任何子策略，附加 `severity=high` 标签会被忽略。

## 继承
<a name="v10-alerting-explore-notifications-inheritance"></a>

子策略除了是路由警报实例的有用概念之外，还继承父策略的属性。这也适用于作为默认通知策略的子策略的任何策略。

以下属性由子策略继承：
+ 联系点
+ 分组选项
+ 定时选项
+ 静音定时

如果您希望覆盖继承的属性，则每个属性都可以由单个策略覆盖。

要从父策略继承联系点，请将其留空。要覆盖继承的分组选项，请启用**覆盖分组**。要覆盖继承的定时选项，请启用**覆盖常规定时**。

### 继承示例
<a name="v10-alerting-explore-notifications-inheritance-example"></a>

下面的示例显示了前面示例中的通知策略树如何允许 `team=operations` 的子策略继承其联系点。

这样，我们可以避免为每个子策略多次指定同一个联系点。

![\[图中以树形结构显示了一组通知策略，其中一些策略分配了联系点，但有些子策略继承了其父策略的联系点，而不是定义自己的联系点。\]](http://docs.aws.amazon.com/zh_cn/grafana/latest/userguide/images/notification-inheritance.png)


## 其他配置选项
<a name="v10-alerting-explore-notifications-additional-configuration-options"></a>

### 分组
<a name="v10-alerting-explore-notifications-grouping"></a>

分组是 Grafana Alerting 的一项重要功能，因为其允许将相关警报批处理合并成数量较少的通知。如果通知是发送给第一响应人员（如值班工程师），这一点尤为重要，因为在短时间内收到大量通知可能会让人不知所措，在某些情况下，还会影响第一响应人员对事故的响应。例如，假设发生一次大面积停机，导致许多系统瘫痪。在这种情况下，分组可能是接听 1 个电话呼叫和 100 个电话呼叫的区别。

您可以使用通知策略中的“分组依据”选项来选择如何将警报分组。默认情况下，Grafana 中的通知策略使用 `alertname` 和 `grafana_folder` 标签按警报规则将警报分组（因为警报名称在多个文件夹中并不唯一）。如果您希望按警报规则以外的方式对警报进行分组，请将分组方式更改为任何其他标签组合。

#### 禁用分组
<a name="v10-alerting-explore-notifications-disable-grouping"></a>

如果您希望将每个警报作为单独的通知接收，可使用一个名为 `...` 的特殊标签进行分组。当警报发送到自动系统而不是第一响应者时，这个功能就非常有用。

#### 所有警报在一个组
<a name="v10-alerting-explore-notifications-a-single-group-for-all-alerts"></a>

如果您希望在一个通知中同时接收所有警报，可以将“分组依据”留空。

### 定时选项
<a name="v10-alerting-explore-notifications-timing-options"></a>

定时选项决定了每组警报发送通知的频率。您需要了解三个定时器：组等待、组间隔和重复间隔。

#### 组等待
<a name="v10-alerting-explore-notifications-group-wait"></a>

组等待是 Grafana 在发送新一组警报的第一条通知之前等待的时间。组等待时间越长，其他警报到达的时间就越长。组等待时间越短，第一条通知发送的就越早，但发送的通知可能不完整。您应始终选择对您的用例最有意义的组等待。

**默认值** 30 秒

#### 组间隔
<a name="v10-alerting-explore-notifications-group-interval"></a>

发送了新一组警报的第一条通知后，Grafana 就会启动组间隔定时器。这是 Grafana 在向组发送更改通知前等待的时间。例如，另一个触发警报可能刚刚添加到组中，而现有警报可能已解决。如果由于组等待而导致警报太晚而无法包含在第一个通知中，则会包含在组间隔之后的后续通知中。组间隔结束后，Grafana 会重置组间隔定时器。如此重复，直到组中不再有警报，然后删除该组。

**默认值** 5 分钟

#### 重复间隔
<a name="v10-alerting-explore-notifications-repeat-interval"></a>

重复间隔决定了在自上次通知以来，组未发生变化的情况下重复通知的频率。您可以将这些视为某些警报仍在触发的提醒。重复间隔与组间隔密切相关，这意味着您的重复间隔不仅必须大于或等于组间隔，还必须是组间隔的倍数。如果重复间隔不是组间隔的倍数，则将被强制转换为一个倍数。例如，如果您的组间隔为 5 分钟，重复间隔为 9 分钟，则重复间隔将四舍五入到最接近的 5 的倍数，即 10 分钟。

**默认值** 4 小时