有一定Zabbix使用经验的小伙伴可能会发现，接收告警事件时，其中可能包含着大量不同的部件名，同一部件的事件在逻辑上具有很强关联性，理论上应保持一致的告警/恢复状态，但Zabbix默认并未对它们进行关联，直接后果是运维人员只能进行大量重复操作，进而对部件的状态进行校正。
从结果中可以看到，部件名称被正则截取到标记中。 同时，只有DIMM110 是既存在”Assertion”记录，又存在”Deassertion”记录的，所以只有DIMM110部件的告警是恢复了的。
优点： 1.配置简单，仅配置一条即可 2.告警事件不遗漏，多个部件告警信息，则产生多个告警事件 3.可以实现单个部件的告警、恢复记录的关联，不会因为其他此部件的恢复记录，触发其他部件告警的恢复操作
缺点： 1.配置逻辑较复杂，涉及标记、正则、内置宏等多方面
优点： 1. 配置简单，仅配置一条即可 2. 告警事件不遗漏，多个部件告警信息，则产生多个告警事件
图5
优点： 1.可以实现单个部件的告警、恢复记录的关联，不会因为其他此部件的恢复记录，触发其他部件告警的恢复操作
缺点： 1.配置工作量巨大，每个部件都需要定义一个对应触发器 2.可能会丢失、遗漏告警，因为可能部件关键字未加入触发器中
结论： 上述三种方法可以看出，逻辑上方法二、方法三更加简单明了，但是皆有不满足场景需求的情况；方法一则更贴合场景需求，且善用触发器的标记功能，也更利于监控平台的维护管理。参考该第一方法，可延伸较多场景，如日志事件告警恢复ID关联、snmptrap端口up\down数据告警关联、硬件事件相同部件名告警恢复关联、远程登入登出记录关联等。 以上就是这一期Zabbix技术分享。大家好，我是乐乐，专注运维技术研究与分享，关注我学习更多Zabbix使用技巧，更多问题也欢迎到乐维社区进行留言。
