触发器(trigger)
① 简介
当我们的采集的值定义完了以后,就可以来定义触发器了。 我们触发器的定义是:界定某特定的item采集到的数据的非合理区间或非合理状态。通常为逻辑表达式。 逻辑表达式(阈值):通常用于定义数据的不合理区间,其结果如下:
OK
(不符合条件):正常状态 --> 较老的zabbix版本,其为FALSE;PROBLEM
(符合条件):非正常状态 --> 较老的zabbix版本,其为TRUE; 一般,我们评定采样数值是否为合理区间的比较稳妥的方法是——根据最后N次的平均值来判定结果;这个最后N次通常有两种定义方式:
- 最近N分钟所得结果的平均值
- 最近N次所得结果的平均值
而且,我们的触发器存在可调用的函数:
nodata() #是否采集到数据,采集不到则为异常 last() #最近几次的平均值 date() time() now() dayofmonth() ...
注:能用数值保存的就不要使用字符串
② 触发器表达式
基本的触发器表达式格式如下所示
{<server>:<key>.<function>(<parameter>)}<operator><constant>
server
:主机名称;key
:主机上关系的相应监控项的key;function
:评估采集到的数据是否在合理范围内时所使用的函数,其评估过程可以根据采取的数据、当前时间及其它因素进行;- 目前,触发器所支持的函数有avg、count、change、date、dayofweek、delta、diff、iregexp、last、max、min、nodata、now、sum等
parameter
:函数参数;大多数数值函数可以接受秒数为其参数,而如果在数值参数之前使用“#”做为前缀,则表示为最近几次的取值,如sum(300)表示300秒内所有取值之和,而sum(#10)则表示最近10次取值之和;- 此外,avg、count、last、min和max还支持使用第二个参数,用于完 成时间限定;例如,max(1h,7d)将返回一周之前的最大值; 表达式所支持的运算符及其功能如下图所示:
③ 定义一个触发器
我们可以查看一下rate of packets(in)
的值,并以其为标准确定我们的非正常的值:
图中我们可以看出,我们的最大值为36,最小值为23,平均值为30。这样的话,我们可以定义50以上的都是非正常的值,这里为了测试定义为30。 下面我们来定义一个触发器: 进入:配置 ---> 主机 ---> node1 ---> 触发器 ---> 创建触发器
我们的表达式可以直接点击右侧的添加,然后定义自己所需的内容,即可自动生成:
生成完毕后,我们就点击页面下方的添加,即成功定义了一个触发器,同时页面自动跳转:
然后我们去看一下我们刚刚定义了触发器的那个监控项:
我们可以看出,这个里面就有了一根线,就是我们刚刚定义的值,超过线的即为异常状态,看起来非常直观。 但是,现在即使超过了这根线,也仅仅会产生一个触发器事件而不会做其他任何事。因此,我们就需要去定义一个动作(action)。
④ 触发器的依赖关系
我们的触发器彼此之间可能会存在依赖关系的,一旦某一个触发器被触发了,那么依赖这个触发器的其余触发器都不需要再报警。 我们可以来试想一下这样的场景: 我们的多台主机是通过交换机的网络连接线来实现被监控的。如果交换机出了故障,我们的主机自然也无法继续被监控,如果此时,我们的所有主机统统报警……想想也是一件很可怕的事情。要解决这样的问题,就是定义触发器之间的依赖关系,当交换机挂掉,只它自己报警就可以了,其余的主机就不需要在报警了。这样,也更易于我们判断真正故障所在。 注意:目前zabbix不能够直接定义主机间的依赖关系,其依赖关系仅能通过触发器来定义。 我们来简单举一个例子,示范一下如何定义一个依赖关系,触发器可以有多级依赖关系,比如我们看下面的例子:
5)定义动作(action)
① 简介
我们需要去基于一个对应的事件为条件来指明该做什么事,一般就是执行远程命令或者发警报。 我们有一个告警升级的机制,所以,当发现问题的时候,我们一般是先执行一个远程操作命令,如果能够解决问题,就会发一个恢复操作的讯息给接收人,如果问题依然存在,则会执行发警报的操作,一般默认的警报接收人是当前系统中有的zabbix用户,所以当有人需要收到警报操作的话,我们则需要把它加入我们的定义之中。 其次,每一个用户也应该有一个接收告警信息的方式,即媒介,就像我们接收短信是需要有手机号的一样。 我们的每一个监控主机,能够传播告警信息的媒介有很多种,就算我们的每一种大的媒介,能够定义出来的实施媒介也有很多种。而对于一个媒介来说,每一个用户都有一个统一的或者不同的接收告警信息的端点,我们称之为目标地或者目的地。 综上,为了能够发告警信息,第一,我们要事先定义一个媒介,第二,还要定义这个媒介上用户接收消息的端点(当然,在用户上,我们也称之为用户的媒介)。 我们可以去看一下系统内建的媒介类型:
这里我们看到,系统已经集成了许多的报警媒介,我们来配置公网邮箱报警
测试成功后,就可以使用配置好的邮件报警媒介了
② 定义一个动作(action)
我们之前说过了,动作是在某些特定条件下触发的,比如,某个触发器被触发了,就会触发我们的动作。 现在,我们基于redis来定义一个动作。 首先,我们在agent端使用yum安装一下redis
:
[root@zabbix-slave1 ~]# yum install redis -y
修改一下配置文件:
[root@zabbix-slave1 ~]# vim /etc/redis.conf
bind 0.0.0.0 #不做任何认证操作
修改完成以后,我们启动服务,并检查端口:
[root@zabbix-slave1 ~]# systemctl start redis
[root@zabbix-slave1 ~]# ss -nutlp | grep redis
tcp LISTEN 0 128 *:6379 *:* users:(("redis-server",pid=5250,fd=4))
接着,我们就可以去网站上来定义相关的操作了:
1.定义监控项
进入 配置 ---> 主机 ---> node1 ---> 监控项(items)---> 创建监控项
填写完毕以后,我们点击下方的添加。
该监控项已成功添加。 我们可以去查看一下他的值: 检测中 ---> 最新数据
2.定义触发器
定义好了监控项以后,我们亦可来定义一个触发器,当服务有问题的时候,我们才能及时知道: 进入 配置 ---> 主机 ---> node1 ---> 触发器(trigger)---> 创建触发器
填写完毕以后,我们点击下方的添加。
该触发器已成功添加。 我们去查看一下: 监测中 ---> 最新数据
我们来手动关闭redis服务来检测一下:
[root@zabbix-slave1 ~]# systemctl stop redis.service
进入 监测中 ---> 问题
可以看到,现在已经显示的是问题了。并且有持续的时间,当我们的服务被打开,会转为已解决状态:
[root@zabbix-slave1 ~]# systemctl start redis.service
3.定义动作(action)
现在我们就可以去定义action了。 进入 配置 ---> 动作 ---> 创建动作(注意选择事件源为触发器)
我们可以进行操作添加:
我们可以看出,还需要在虚拟机上进行两项操作,一是修改sudo配置文件使zabbix用户能够临时拥有管理员权限;二是修改zabbix配置文件使其允许接收远程命令。我们进行如下操作:
[root@zabbix-slave1 ~]# visudo #相当于“vim /etc/sudoers”
## Allow root to run any commands anywhere
root ALL=(ALL) ALL
zabbix ALL=(ALL) NOPASSWD: ALL #添加的一行,表示不需要输入密码
[root@zabbix-slave1 ~]# vim /etc/zabbix/zabbix_agentd.conf
EnableRemoteCommands=1 #允许接收远程命令 修改原有的值,不要在末尾追加
LogRemoteCommands=1 #把接收的远程命令记入日志
[root@zabbix-slave1 ~]# systemctl restart zabbix-agent.service
我们添加了第一步需要做的事情,也就是重启服务,如果重启不成功怎么办呢?我们就需要来添加第二步:
添加完成以后,我们可以看一下:
操作添加完了,如果服务自动恢复了,我们可以发送消息来提示:
至此,我们的动作设置完毕,可以点击添加了,添加完成会自动跳转至如下页面:
现在我们可以手动停止服务来进行测试:
[root@zabbix-slave1 ~]# systemctl stop redis.service
然后我们来到问题页面来查看,发现确实有问题,并且已经解决:
我们可以去查看是否收到邮件 也可以去agent端查看端口是否开启:
[root@zabbix-slave1 ~]# systemctl stop redis.service
[root@zabbix-slave1 ~]# ss -ntl
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 *:6379 *:*
LISTEN 0 128 *:111 *:*
LISTEN 0 5 192.168.122.1:53 *:*
LISTEN 0 128 *:22 *:*
LISTEN 0 128 127.0.0.1:631 *:*
LISTEN 0 128 *:23000 *:*
LISTEN 0 100 127.0.0.1:25 *:*
LISTEN 0 128 *:10050 *:*
LISTEN 0 128 :::111 :::*
LISTEN 0 128 :::22 :::*
LISTEN 0 128 ::1:631 :::*
LISTEN 0 100 ::1:25 :::*
可以看出端口正常开启,我们的动作触发已经完成。
补充:我们也可以使用脚本来发送警报,我们的脚本存放路径在配置文件中可以找到,定义为:
AlterScriptsPath=/usr/lib/zabbix/alertscripts
接下来,我们来一波彻底一点的操作,我们来手动修改一下redis服务的监听端口,这样,我们就不能通过重启服务恢复了:
[root@zabbix-slave1 ~]# vim /etc/redis.conf
#port 6379
port 6380 #注释掉原来的端口,更换为新的端口
[root@zabbix-slave1 ~]# systemctl restart redis
然后,我们来网页查看一下状态: 进入 监测中 ---> 问题,可以看到是报错的:
这样,在经过了重启服务以后还是没能把解决问题,就会发邮件告警:
我们再把服务端口改回来,然后重启服务。这样,等到问题自动解决了以后,我们会再次收到邮件:
这样,我们的动作设定已经全部测试完成。