触发器（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然后，我们来网页查看一下状态： 进入 监测中 ---> 问题，可以看到是报错的：
这样，在经过了重启服务以后还是没能把解决问题，就会发邮件告警：
我们再把服务端口改回来，然后重启服务。这样，等到问题自动解决了以后，我们会再次收到邮件：
这样，我们的动作设定已经全部测试完成。
1061
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
