zabbix事件告警监控：如何实现对相同部件触发器告警及恢复的强关联

有一定Zabbix使用经验的小伙伴可能会发现，接收告警事件时，其中可能包含着大量不同的部件名，同一部件的事件在逻辑上具有很强关联性，理论上应保持一致的告警/恢复状态，但Zabbix默认并未对它们进行关联，直接后果是运维人员只能进行大量重复操作，进而对部件的状态进行校正。

实际上，虽然Zabbix默认未对相同部件进行关联，但却可以通过手动配置实现关联操作。本文将深入探讨Zabbix在处理相同部件触发器的告警和恢复过程中的强关联机制。通过这种机制，我们可以确保一旦触发器状态发生变化，相关的告警能够被准确触发，并且在问题解决后，告警状态能够及时恢复，从而避免无效告警的干扰和资源的浪费。

例如，当前监控中有对硬件设备事件采集监控项（数据如下），要对其配置触发器告警，但是每个事件中包含告警对应的部件名，希望对相同部件的告警实现告警-恢复事件的自动关联。
数据字段解析：

监控取值中，第4位为告警状态，"Assertion"表示告警产生，"Deassertion"表示告警恢复。

配置思路：
方法一(建议)：
参考方法二中基础配置，额外补充事件匹配-标签

标记中“值“参数支持写法如下

{{ITEM.VALUE}.regsub(pattern, output)}

{{ITEM.VALUE}.iregsub(pattern, output)}

{{#LLDMACRO}.regsub(pattern, output)}

{{#LLDMACRO}.iregsub(pattern, output)}

图中示例写法：

{{ITEM.VALUE}.regsub(“tion”,\s*“\s*(\S+)\s*(”,\1)}

测试数据如下：

测试结果：
从结果中可以看到，部件名称被正则截取到标记中。

同时，只有DIMM110 是既存在”Assertion”记录，又存在”Deassertion”记录的，所以只有DIMM110部件的告警是恢复了的。

优点：

1.配置简单，仅配置一条即可

2.告警事件不遗漏，多个部件告警信息，则产生多个告警事件

3.可以实现单个部件的告警、恢复记录的关联，不会因为其他此部件的恢复记录，触发其他部件告警的恢复操作

缺点：

1.配置逻辑较复杂，涉及标记、正则、内置宏等多方面

方法二：
配置单个触发器，如下图2

①将告警最新值带进告警标题中，区分具体告警部件等信息。

②检测到关键字"Assertion"则告警

③检测到关键字"Deassertion"则恢复

④问题事件生成模式：多重：触发器未恢复的情况下可以多次产生告警；单个：多次规则匹配，如果已经产生的告警为恢复的情况下，不会重新产生新告警。效果如下图3

优点：

1. 配置简单，仅配置一条即可

2. 告警事件不遗漏，多个部件告警信息，则产生多个告警事件

缺点：

1.一个部件告警恢复，则其他部件告警一并恢复，如图4 —— 仅DIMM131部件恢复，其他部件的告警也被恢复了，其实并没有

方法三：
对每个部件添加一个触发器（如下图5）：

DIMM110部件告警触发器：

触发表达式：监控值包含DIMM110 且 包含关键字 “Assertion”；

恢复表达式：监控值包含DIMM110 且 包含关键字 “Deassertion”；

反复操作，添加DIMM111、DIMM120、DIMM121等多个触发器。

图5

优点：

1.可以实现单个部件的告警、恢复记录的关联，不会因为其他此部件的恢复记录，触发其他部件告警的恢复操作

缺点：

1.配置工作量巨大，每个部件都需要定义一个对应触发器

2.可能会丢失、遗漏告警，因为可能部件关键字未加入触发器中

结论：
上述三种方法可以看出，逻辑上方法二、方法三更加简单明了，但是皆有不满足场景需求的情况；方法一则更贴合场景需求，且善用触发器的标记功能，也更利于监控平台的维护管理。参考该第一方法，可延伸较多场景，如日志事件告警恢复ID关联、snmptrap端口up\down数据告警关联、硬件事件相同部件名告警恢复关联、远程登入登出记录关联等。

以上就是这一期Zabbix技术分享。大家好，我是乐乐，专注运维技术研究与分享，关注我学习更多Zabbix使用技巧，更多问题也欢迎到乐维社区进行留言。