本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
通知政策
本文档主题专为支持 Grafana 版本 10.x 的 Grafana 工作空间而设计。
有关支持 Grafana 9.x 版本的 Grafana 工作空间,请参阅。在 Grafana 版本 9 中工作
有关支持 Grafana 8.x 版本的 Grafana 工作空间,请参阅。在 Grafana 版本 8 中工作
通知策略为您提供了一种灵活的方式,可以将警报路由到不同的接收者。使用标签匹配器,您可以修改警报通知的发送,而不必更新每条警报规则。
在本节中,您将详细了解通知政策的工作原理和结构,以便您可以充分利用通知策略的设置。
策略树
通知策略不是列表,而是根据树形结构进行结构化的。这意味着每份保单都可以有子女保单,依此类推。通知策略树的根称为默认通知策略。
每个策略都由一组标签匹配器(0 或更多)组成,用于指定他们对处理哪些标签感兴趣或不感兴趣。
有关标签匹配的更多信息,请参阅标签匹配的工作原理。
注意
如果您尚未为通知策略配置任何标签匹配器,则您的通知策略将匹配所有警报实例。除非您在通知策略上启用了 “继续匹配兄弟姐妹”,否则这可能会阻止对子政策进行评估。
路由
要确定哪个通知策略将处理哪些警报实例,您必须首先查看现有的一组通知策略,首先是默认的通知策略。
如果除了默认策略之外没有配置任何策略,则默认策略将处理警报实例。
如果定义了默认策略以外的策略,它将按照这些通知策略的显示顺序对其进行评估。
如果通知策略的标签匹配器与警报实例的标签相匹配,则它将进入其子政策,如果有,则将继续寻找任何可能具有标签匹配器以进一步缩小标签集范围的子政策,依此类推,直到找不到更多子政策。
如果通知策略中未定义子策略,或者子策略中没有任何与警报实例标签匹配的标签匹配器,则使用父通知策略。
一旦找到匹配的策略,系统就不会继续寻找其他匹配的策略。如果您想继续寻找可能匹配的其他策略,请在该特定策略上启用 “继续匹配兄弟姐妹”。
最后,如果未选择任何通知策略,则使用默认通知策略。
路由示例
以下是一个相对简单的通知策略树和一些警报实例的示例。
以下是如何选择这些政策的明细:
卡在里 CrashLoop面的 Pod 没有severity
标签,因此其子策略都不匹配。它确实有一个team=operations
标签,所以第一个策略是匹配的。
由于我们已经找到了匹配项,并且没有为该team=security
策略配置 “继续匹配兄弟姐妹”,因此未对该策略进行评估。
磁盘使用率 — 80% 同时具有team
和severity
标签,并且与运营团队的子政策相匹配。
未经授权的日志条目有team
标签,但与第一个策略 (team=operations
) 不匹配,因为两者的值不相同,因此它将继续搜索并匹配team=security
策略。它没有任何儿童政策,因此附加severity=high
标签将被忽略。
继承
除了子策略是路由警报实例的有用概念外,它们还继承父策略的属性。这也适用于作为默认通知策略的子策略的任何策略。
以下属性由子策略继承:
联络点
分组选项
定时选项
静音计时
如果您希望覆盖继承的属性,则每个属性都可以由单个策略覆盖。
要继承父政策中的联系人,请将其留空。要覆盖继承的分组选项,请启用 “覆盖分组”。要覆盖继承的计时选项,请启用 “覆盖常规计时”。
继承示例
以下示例显示了我们上一个示例中的通知策略树如何允许的team=operations
子政策继承其联系人。
通过这种方式,我们可以避免为每份儿童保单多次指定同一个联系点。
其他配置选项
分组
分组是 Grafana Alerting 的一项重要功能,因为它允许您将相关警报批处理成数量较少的通知。如果向急救人员(例如待命工程师)发送通知,这一点尤其重要,因为在短时间内收到大量通知可能会让人不知所措,在某些情况下,还会对急救人员应对事件的能力产生负面影响。例如,假设一次大规模中断,您的许多系统都停机了。在这种情况下,分组可能是接听 1 个电话和 100 个电话的区别。
您可以使用通知策略中的 “分组依据” 选项来选择如何将警报分组在一起。默认情况下,Grafana 中的通知策略使用grafana_folder
和标签按警报规则将警报分组在一起(因为警报名称alertname
在多个文件夹中不是唯一的)。如果您希望按警报规则以外的内容对警报进行分组,请将分组更改为任何其他标签组合。
禁用分组
如果您希望将每条警报作为单独的通知接收,则可以通过按名为的特殊标签进行分组来实现...
。当您的警报发送到自动系统而不是第一响应者时,这很有用。
一个群组处理所有警报
如果您希望在单个通知中同时接收所有警报,则可以将 Group by 留空。
定时选项
计时选项决定每组警报发送通知的频率。您需要了解三个计时器:分组等待、分组间隔和重复间隔。
群组等待
群组等待是 Grafana 在发送新一组警报的第一条通知之前等待的时间。群组等待时间越长,其他警报到达的时间就越长。群组等待时间越短,发送的第一条通知就越早,但可能会发送不完整的通知。您应该始终选择最适合您的用例的群组等待。
默认 30 秒
分组间隔
针对新一组警报发送第一条通知后,Grafana 就会启动群组间隔计时器。这是 Grafana 在向群组发送有关变更的通知之前等待的时间。例如,另一个触发警报可能刚刚添加到群组中,而现有警报可能已经解决。如果由于群组等待而导致警报为时已晚,无法包含在第一份通知中,则该警报将在群组间隔之后包含在后续通知中。群组间隔结束后,Grafana 会重置群组间隔计时器。这种情况会一直重复,直到该组中不再有警报,之后该组就会被删除。
默认 5 分钟
重复间隔
重复间隔决定如果群组自上次通知以来未发生更改,则重复通知的频率。你可以把它们看作是提醒一些警报仍在触发。重复间隔与组间隔密切相关,这意味着您的重复间隔不仅必须大于或等于组间隔,而且必须是组间隔的倍数。如果重复间隔不是 Group 间隔的倍数,则它将被强制转换为一个。例如,如果您的 “分组” 间隔为 5 分钟,“重复间隔” 为 9 分钟,则重复间隔将向上舍入为 5 的最接近的倍数,即 10 分钟。
默认 4 小时