Alertmanager 抑制规则深度解析：equal、source_matchers、target_matchers 详解与避坑指南

各位老铁，大家好！我是你们的 SRE 好伙伴，码农老王。

今天咱们来聊聊 Alertmanager 的抑制规则，特别是 equal、source_matchers 和 target_matchers 这三个参数。相信不少用过 Alertmanager 的兄弟都遇到过告警风暴，或者告警被莫名其妙抑制的情况。别慌，老王今天就带你深入理解这几个参数，让你彻底告别这些烦恼。

什么是抑制规则？

在聊具体参数之前，咱们先来明确一下什么是抑制规则。简单来说，抑制规则就是用来防止告警风暴的。当一个告警触发后，可能会引发一系列相关的告警，如果我们不加控制，就会收到大量的重复或相似的告警，这就是告警风暴。抑制规则的作用就是，当一个“更高级别”的告警触发后，自动抑制那些“低级别”的、相关的告警，从而避免告警风暴。

举个例子：假设你监控了机房的网络，设置了“机房核心交换机宕机”和“服务器网络不可达”两个告警。如果核心交换机真的宕机了，那么所有连接到这个交换机的服务器肯定都会报“网络不可达”的告警。这时候，如果你配置了抑制规则，让“机房核心交换机宕机”这个告警抑制“服务器网络不可达”告警，那么你就只会收到一条核心交换机宕机的告警，而不会被服务器网络不可达的告警淹没。

抑制规则的配置

Alertmanager 的抑制规则是在 alertmanager.yml 配置文件中的 inhibit_rules 部分定义的。一个典型的抑制规则配置如下：

inhibit_rules:
- source_matchers:
  - severity = 'critical'
  target_matchers:
  - severity = 'warning'
  equal: ['alertname', 'instance']

这个配置的意思是：当一个 severity 为 critical 的告警触发后，所有 severity 为 warning，且 alertname 和 instance 标签都相同的告警都会被抑制。

下面，我们就来详细解释一下 equal、source_matchers 和 target_matchers 这三个参数。

source_matchers

source_matchers 用于匹配那些“更高级别”的告警，也就是触发抑制规则的告警。它是一个匹配器列表，每个匹配器都必须匹配成功，这个抑制规则才会被触发。匹配器使用和Prometheus查询标签时一样的语法。

例如：

source_matchers:
  - severity = 'critical'
  - alertname = 'HighErrorRate'

这个配置表示，只有当一个告警的 severity 标签为 critical，且 alertname 标签为 HighErrorRate 时，才会触发这个抑制规则。

注意事项：

• source_matchers 必须至少包含一个匹配器。
• 所有 source_matchers 中的匹配器都必须匹配成功，抑制规则才会被触发。 可以理解为与的关系

target_matchers

target_matchers 用于匹配那些“低级别”的告警，也就是被抑制的告警。它也是一个匹配器列表，每个匹配器都必须匹配成功，这个告警才会被抑制。匹配器使用和Prometheus查询标签时一样的语法。

例如：

target_matchers:
  - severity = 'warning'
  - alertname = 'LowDiskSpace'

这个配置表示，只有当一个告警的 severity 标签为 warning，且 alertname 标签为 LowDiskSpace 时，才会被这个抑制规则抑制。

注意事项：

• target_matchers 必须至少包含一个匹配器。
• 所有 target_matchers 中的匹配器都必须匹配成功，告警才会被抑制。可以理解为与的关系

equal

equal 参数用于指定一组标签，这些标签的值必须在源告警和目标告警中完全相同，目标告警才会被抑制。这个参数的作用是进一步细化抑制规则的匹配范围，避免误伤。

例如：

equal: ['alertname', 'instance']

这个配置表示，只有当源告警和目标告警的 alertname 和 instance 标签的值都相同时，目标告警才会被抑制。

注意事项：

• equal 参数是可选的，如果不指定，则表示源告警和目标告警不需要任何标签相同。
• equal 中列出的标签必须同时存在于源告警和目标告警中，否则抑制规则不会生效。如果equal中指定的标签在source_matchers和target_matchers中作为匹配条件, 则也会检查这些标签

案例分析

下面，我们通过几个案例来进一步理解这三个参数的作用。

案例一：抑制同实例的低级别告警

假设我们有两个告警：

• HighCPUUsage (severity=critical, instance=host1)
• HighMemoryUsage (severity=warning, instance=host1)

我们希望当 HighCPUUsage 告警触发时，抑制 HighMemoryUsage 告警。我们可以这样配置：

inhibit_rules:
- source_matchers:
  - severity = 'critical'
  - alertname = 'HighCPUUsage'
  target_matchers:
  - severity = 'warning'
  - alertname = 'HighMemoryUsage'
  equal: ['instance']

这个配置表示，当 HighCPUUsage 告警触发时，所有 severity 为 warning，alertname 为 HighMemoryUsage，且 instance 标签相同的告警都会被抑制。因为 HighCPUUsage 和 HighMemoryUsage 的 instance 标签都是 host1，所以 HighMemoryUsage 告警会被抑制。

案例二：避免误伤不同实例的告警

假设我们有两个告警：

• HighCPUUsage (severity=critical, instance=host1)
• HighMemoryUsage (severity=warning, instance=host2)

如果我们使用和案例一相同的配置，HighMemoryUsage 告警不会被抑制，因为它们的 instance 标签不同。

案例三：不使用 equal 参数

如果我们把案例一中的 equal 参数去掉：

inhibit_rules:
- source_matchers:
  - severity = 'critical'
  - alertname = 'HighCPUUsage'
  target_matchers:
  - severity = 'warning'
  - alertname = 'HighMemoryUsage'

那么，无论 HighMemoryUsage 告警的 instance 标签是什么，只要 HighCPUUsage 告警触发，它都会被抑制。这可能会导致误伤，因为不同实例的 HighMemoryUsage 告警可能并不相关。

案例四: 使用equal和matchers匹配相同标签
假设我们有两个告警:

• HighCPUUsage (severity=critical, alertname='CPUAlert', instance=host1, region=us-east-1)
• HighMemoryUsage (severity=warning, alertname='MemAlert', instance=host1, region=us-east-1)

抑制规则:

inhibit_rules:
- source_matchers:
    - alertname = 'CPUAlert'
    - region = 'us-east-1'
  target_matchers:
    - alertname = 'MemAlert'
    - region = 'us-east-1'
  equal: ['instance', 'region']

即使region同时出现在source_matchers, target_matchers和equal中， 抑制规则依旧会检查源告警和目标告警的instance和region标签是否相同。只有当instance和region都匹配时，HighMemoryUsage才会被抑制。

常见陷阱与最佳实践

1. 过度抑制： 抑制规则配置过于宽松，导致重要的告警被抑制。避免方法：仔细规划 source_matchers、target_matchers 和 equal 参数，确保只抑制那些真正相关的告警。
2. 抑制不足： 抑制规则配置过于严格，导致告警风暴。避免方法：根据实际情况调整抑制规则，确保能够有效抑制相关的告警。
3. 忽略 equal 参数： 忘记配置 equal 参数，导致误伤。避免方法：根据告警的标签，合理配置 equal 参数，避免误伤不同实例或不同服务的告警。
4. 标签缺失： equal 中指定的标签在源告警或目标告警中不存在，导致抑制规则不生效。避免方法：确保 equal 中列出的标签同时存在于源告警和目标告警中。
5. 理解source_matchers和target_matchers中的与关系: 确保所有匹配器都匹配成功, 抑制规则才会生效. 不要错误地理解为或关系.

最佳实践：

• 从小范围开始：先配置一个简单的抑制规则，然后逐步扩大范围，避免一次性配置过于复杂的规则。
• 测试：在测试环境中充分测试抑制规则，确保其符合预期。
• 监控：监控 Alertmanager 的日志，观察抑制规则的执行情况，及时发现问题。
• 文档：记录抑制规则的设计思路和配置细节，方便后续维护和排查问题。

总结

好了，老铁们，关于 Alertmanager 抑制规则中的 equal、source_matchers 和 target_matchers 参数，今天就聊到这里。希望这篇文章能帮助你更好地理解和使用 Alertmanager 的抑制规则，避免告警风暴，提高运维效率。

记住，抑制规则是一把双刃剑，用好了可以事半功倍，用不好可能会适得其反。所以，一定要仔细规划，谨慎配置，并在实践中不断总结经验。如果你还有其他问题，欢迎在评论区留言，老王会尽力解答。

最后，祝大家工作顺利，告警远离！