大家好，我是你们的 SRE 伙伴，昵称“容器老司机”。今天咱们来聊聊 Alertmanager 的抑制规则，特别是其中的 equal、source_matchers 和 target_matchers 这三个参数。相信不少用过 Alertmanager 的运维工程师都遇到过告警风暴，或者告警抑制不生效的情况。别担心，看完这篇文章，你就能掌握抑制规则的精髓，告别烦恼！
为什么要用抑制规则？
在正式讲解参数之前，咱们先来明确一下，为什么要用抑制规则？
想象一下，如果你的 Kubernetes 集群中某个核心组件（比如 etcd）挂了，会发生什么？
很可能，依赖于这个组件的 N 多个服务都会跟着挂掉，然后 Prometheus 就会疯狂地发出告警，你的手机、邮箱、钉钉瞬间被各种告警信息淹没…… 这就是典型的“告警风暴”。
这时候，你最想看到的，其实是 etcd 挂掉的那个“根因告警”，而不是一堆衍生告警。抑制规则就是用来解决这个问题的：当一个高级别告警（根因告警）触发时，自动抑制由它引起的低级别告警（衍生告警）。
这样，你就能专注于解决根本问题，而不是被海量告警信息淹没。
抑制规则的配置语法
Alertmanager 的抑制规则是在 inhibit_rules 部分定义的，一个典型的配置如下：
inhibit_rules:
- source_matchers:
- alertname = 'HighLevelAlert'
target_matchers:
- alertname = 'LowLevelAlert'
equal: ['instance']
这个配置的意思是：如果 HighLevelAlert 告警被触发，那么所有 instance 标签值相同的 LowLevelAlert 告警都会被抑制。
现在，我们来详细解读 equal、source_matchers 和 target_matchers 这三个参数。
source_matchers
source_matchers 用于匹配触发抑制规则的“源告警”（高级别告警）。它是一个匹配器列表，只有当所有匹配器都匹配成功时，抑制规则才会被激活。
匹配器类型：
source_matchers支持所有 Prometheus 标签匹配器类型，包括：=：精确匹配!=：不匹配=~：正则表达式匹配!~：正则表达式不匹配
使用场景举例：
抑制由特定服务故障引起的告警：
source_matchers: - alertname = 'ServiceDown' service = 'api-server'抑制由特定节点故障引起的告警：
source_matchers: - alertname = 'NodeDown' instance = 'node-1'
target_matchers
target_matchers 用于匹配需要被抑制的“目标告警”（低级别告警）。它也是一个匹配器列表，只有当所有匹配器都匹配成功，并且 source_matchers 也匹配成功时，目标告警才会被抑制。
- 匹配器类型：与
source_matchers相同。 - 使用场景举例：
抑制由
ServiceDown引起的PodDown告警：target_matchers: - alertname = 'PodDown'抑制特定命名空间下的所有告警：
target_matchers: - alertname =~ '.*' namespace = 'staging'
equal
equal 参数是抑制规则中最容易让人困惑的地方。它指定了一个标签列表，用于比较源告警和目标告警。只有当这些标签的值在源告警和目标告警中都相等时，目标告警才会被抑制。
作用：
equal参数的作用是确保抑制规则只作用于“相关”的告警。例如，如果HighLevelAlert和LowLevelAlert都有instance标签，并且equal: ['instance']，那么只有当两个告警的instance标签值相同时，LowLevelAlert才会被抑制。这样可以避免误伤其他不相关的告警。使用场景举例：
抑制同一实例上的多个告警：
equal: ['instance']抑制同一服务的多个告警, 并且这些服务部署在同一个命名空间:
equal: ['service','namespace']
注意事项：
equal列表中的标签必须同时存在于源告警和目标告警中，否则抑制规则不会生效。- 如果
equal列表为空，则表示只要source_matchers和target_matchers匹配成功，目标告警就会被抑制，不进行任何标签比较。这种情况要慎用，容易导致过度抑制。
常见配置陷阱及规避方法
了解了三个参数的作用后，我们来看看实战中容易遇到的坑，以及如何避免。
陷阱一：equal 标签缺失
这是最常见的错误。如果 equal 列表中的标签在源告警或目标告警中不存在，抑制规则就不会生效。所以, 在配置的时候, 务必检查源告警和目标告警的标签。
举例：
假设你有以下告警规则：
# Prometheus 告警规则
- alert: NodeDown
expr: up{job='node-exporter'} == 0
labels:
severity: critical
instance: '{{ $labels.instance }}'
- alert: PodDown
expr: kube_pod_status_phase{phase=~"Failed|Pending",job="kube-state-metrics"} == 1
labels:
severity: warning
pod: '{{ $labels.pod }}'
namespace: '{{ $labels.namespace }}'
你想配置一个抑制规则，当 NodeDown 触发时，抑制同一节点上的 PodDown 告警。你可能会这样配置：
# Alertmanager 抑制规则（错误示例）
inhibit_rules:
- source_matchers:
- alertname = 'NodeDown'
target_matchers:
- alertname = 'PodDown'
equal: ['instance']
这个配置看起来没问题，但实际上不会生效。因为 PodDown 告警中没有 instance 标签，只有 pod 和 namespace 标签。所以应该将equal修改成如下内容:
equal: ['namespace']
并且为PodDown添加一个instance标签, 值和NodeDown中的instance相同:
instance: '{{ $labels.node }}'
陷阱二：过度抑制
如果 equal 列表为空，或者 equal 列表中的标签过于宽泛，可能会导致过度抑制，把不相关的告警也给抑制掉了。
举例：
# Alertmanager 抑制规则（错误示例）
inhibit_rules:
- source_matchers:
- alertname = 'HighLevelAlert'
target_matchers:
- alertname = 'LowLevelAlert'
equal: [] # 过于宽泛
这个配置会导致所有 LowLevelAlert 告警都被抑制，不管它们是否与 HighLevelAlert 相关。正确的做法是根据实际情况，选择合适的标签进行比较。
陷阱三：source_matchers 和 target_matchers 过于严格
如果 source_matchers 或 target_matchers 配置得过于严格，可能会导致抑制规则无法匹配到任何告警，从而无法生效。
举例：
# Alertmanager 抑制规则（错误示例）
inhibit_rules:
- source_matchers:
- alertname = 'NodeDown'
instance = 'node-1.example.com'
region = 'us-east-1'
target_matchers:
- alertname = 'PodDown'
instance = 'node-1.example.com'
equal: ['instance']
这个配置要求 NodeDown 告警必须同时包含 instance 和 region 标签，并且 instance 标签的值必须是 node-1.example.com。如果你的告警规则中没有 region 标签，或者 instance 标签的值略有不同（比如 node-1），这个抑制规则就不会生效。
规避方法：
- 仔细检查你的告警规则，确保
source_matchers和target_matchers中的标签和值都是正确的。 - 尽量使用正则表达式匹配 (
=~)，而不是精确匹配 (=)，以增加灵活性。 - 在测试环境中充分测试你的抑制规则，确保它们能够按预期工作。
最佳实践
最后，总结一些 Alertmanager 抑制规则的最佳实践：
- 从粗到细，逐步细化： 先配置比较宽泛的抑制规则，然后在实际运行中根据告警情况逐步细化，避免一开始就配置过于复杂的规则。
- 充分测试： 在测试环境中充分测试你的抑制规则，模拟各种故障场景，确保它们能够按预期工作。
- 监控 Alertmanager： 监控 Alertmanager 本身的状态和性能，确保它能够及时处理告警。
- 文档化： 将你的抑制规则文档化，方便团队成员理解和维护。
- 善用
continue路由选项: 抑制规则只对当前路由块生效, 如果希望抑制规则对通知到多个接收器的告警都生效, 需要在路由配置中将continue设置为true.
总结
Alertmanager 的抑制规则是一个强大的工具，可以帮助你有效减少告警噪音，专注于解决根本问题。通过理解 equal、source_matchers 和 target_matchers 这三个参数的作用，并结合实际案例避免常见陷阱，你就能成为 Alertmanager 抑制规则的高手！
希望这篇文章对你有所帮助。如果你还有其他问题，或者有更好的实践经验，欢迎在评论区留言交流！
