Zabbix, Nagios告警规则比较

首先说说我比较熟悉的Zabbix的告警规则。
Zabbix是通过触发器实现告警的，触发器主要是对数据现（item)进行分析，如果条件满足，就可以产生告警(Action)，也叫做动作，比如发送Email或者短信。Zabbix的触发器的实现主要是依赖于触发器的表达式，例如：

{www.zabbix.com:system.cpu.load[all,avg1].last()}>5

表示对system.cpu.load[all,avg1]（一个指标或数据项）的最后一个值（倒数第一个值）如果大于5是，表示CPU负载过高，如果希望获取倒数第3个的值，可以采用last(3#)的写法，最好判断CPU负载过高的方法可以采用求平均的方法，比如avg(60)，可以获取的最近1分钟内的平均值。这就是Zabbix的告警规则强大之处。具体表达式参考可以参考Zabbix文档触发器文档, 支持的函数文档。
通过这些函数，就可以实现告警延时和防抖。
告警延时确认可以通过：（假设A主机，x.1数据现，0正常，1告警）
{A:x.1.last(1#)} >0 and {A:x.1. last(2#)}>0, <– 最近两次数据都大于0
或者{A:x.1.avg(10#)}>=10 <–最近10次数据都是大于0
或者count(10#, 1)=10 <–最近10次数据都是等于1（大于0）
这样恢复告警也需要等待一定的时间，这样就可以对告警进行多次确认了，从而防止了偶然的抖动。
Zabbix这样的设计实在是太赞了。

另外，Zabbix通过依赖关系实现告警屏蔽，比如，机房路由器故障会导致后端的交换机和服务器网络故障，如果希望在路由器故障是屏蔽后端设备的网络故障，可以通过配置触发器的依赖来实现。
假设路由器1，路由器2和主机3个设备，连接关系：路由器1<–路由器2<–主机，配置如下依赖关系：
‘主机网络故障’ 触发器依赖于 ‘路由器2网络故障’ 触发器
‘路由器2网络故障’ 触发器依赖于 ‘路由器1网络故障’ 触发器
这样，主机网络故障只有在路由器1没有故障的情况下才会通知用户，路由器2故障只有在路由器1没有故障的情况下才会通知用户，这样用户就不会在网络出现故障时，接收到过多的无意义告警，实现了告警屏蔽。告警屏蔽的官方文档

Nagios的告警规则
由于对Nagios的规则并不是很熟悉，最近在考虑设计一套高实时性能的告警系统，需要了解一下Nagios的规则，请专家多批评指正。
Nagios的告警是通过Status Type（状态类型）来实现告警的延时的。状态类型有两种，SOFT和HARD。何谓SOFT？即虚告警。在告警刚产生的时候，不能立即通知用户，需要等待一段时间，再虚告警阶段，可以对事件进行处理，如果在SOFT状态下采集特定次数（可配置）的非告警状态（WARNING, CRITICAL…)，SOFT告警会升级到HARD状态，这个时候，就会发送通知事件（用户会收到邮件或者短信）。Status Type参考文档

告警屏蔽：Nagios也是通过依赖实现的，不过实现方式和Zabbix有不同。Nagios是通过服务依赖实现的，以上面的示例，那么在配置文件中需要配置主机的依赖关系，这样告警时，由于依赖关系的存在，告警的计算也会抑制，从而实现了告警的屏蔽。详细可参考官方文档

本文从告警的策略和告警屏蔽对Zabbix和Nagios进行了对比，发现都各具优势。对于Zabbix的函数式设计，本文觉得是一个非常好的办法，不过使用门槛较高，通过UI生成函数表达式在Zabbix UI中目前已经实现，不过还是不直观，非专业人员无法理解。Nagios的插件设计使得他可以得到广泛的支持，同时通过服务/主机的依赖关系，可以减少依赖关系的配置，这一点是基于触发器的依赖所不能具有的。