zabbix告警事件对相同组件触发器告警及恢复的强关联性

一、简介

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

虽然Zabbix默认不对相同组件进行关联，但却可以通过配置实现强关联操作，接下来将探讨Zabbix在处理相同组件触发器的告警/恢复过程中的强关联机制。可通过这种机制确保一旦触发器状态发生变化，相关的告警能够被准确触发，并且在问题解决之后，告警状态能够及时恢复，进而避免无效告警干扰和资源浪费情况。

二、配置样例

当前监控对硬件设备事件采集监控项(样例数据如下)，进而对其配置触发器告警，但是每个事件中包含告警对应的组件名，希望对相同组件的告警实现告警/恢复事件的自动关联关系的情况之下：

最新数据显示字段如图：

要求：监控项最新数据中，第4位为告警状态，"Assertion"表示告警产生，"Deassertion"表示告警恢复

1.建议配置方法一

事件匹配-标签方式

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

{{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.建议配置方法二

配置单个触发器，如下图所示

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

2.检测到关键字"Assertion"则告警

3.检测到关键字"Deassertion"则恢复

4.问题事件生成模式：

多重：触发器未恢复的情况下可以多次产生告警；

单个：多次规则匹配，如果已经产生的告警为恢复的情况下，不会重新产生新告警

优点：

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

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

缺点：

一个组件告警恢复，则其它组件告警一并恢复如下图所示： 仅DIMM131组件恢复，其它组件的告警也被恢复了，但其实其它组件并没有恢复

3.建议配置方法三

对每个组件添加一个触发器如下图所示：

DIMM110部件告警触发器：

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

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

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

优点：

可实现单个组件的告警、恢复记录的关联，不会因为其它此组件的恢复记录而恢复，触发其它组件的告警恢复操作；

缺点：

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

2.可能会丢失事件、遗漏告警，可能存在组件关键字未添加触发器规则；

三、总结

综上所述三种方法可看出，从逻辑上方法二、方法三配置简单明了，但皆有不满足需求场景的情况，方法一则更贴合实际需求场景，且Zabbix的标记功能是非常适合不同应用情况下的场景，也利于Zabbix维护及管理。建议方法一，可延伸较多场景，比如日志事件告警恢复ID关联、snmptrap、端口up/down数据告警关联、硬件事件相同组件名告警恢复关联、远程登入登出记录关联等等。

探索技术无限可能，博主具有丰富监控模板资源及开发能力和项目管理经验，欢迎添加交流一起探讨，解决你的技术难题！

微信号:king_songax