（7）配置server，添加host：
注意：配置Hosts时，一定要注意，"Host name"一定要和zabbix_agentd.conf配置文件中定义hostname一致！否则会出现类似"cannot send list of active checks to "192.168.109.8": host [node2.com] not found"报错；
（8）定义item：
术语：
host groups --> host --> application --> item --> trigger --> action (conditions, operations)
graph：
simple：每个item定义完成后自动生成；
customed：用于将多个item的数据整合于一个图形中展示；
items：key+parameter（key+参数）
注意：parameter就是被监控端需要执行的命令，或者是某个Agent中的代码段，执行完之后，可以得到的用户关注信息；
key：key可以理解为命令，内建key+用户自定义的Parrameter；
zabbix内建：
type：
agent (server:pull)
agent(active) (agent:push)
snmp v1...
注意：选择type类型时，一定要和选择的接口一致（数据采集的信道），不同的信道对应的key对应着不同的内建key；
用户自定义(UserParameter)：用户自定义的参数；
注意：建议尽量的使用内建key，效率比较快，性能比较高；
采集到的数据的类型：
数值：整数、浮点数；
字符串：字符串、文本；
存储的值：
As is：不对数据做任何处理；
Delta：（simple change)，本次采样减去前一次采样的值的结果；
Delta：（speed per second)，本次采样减去前一次采样的值，除以经过的时长；
注意：对于3.0之后的版本中，zabbix增加了Preprocessing(预处理)的功能；
注意：实际生产中，刷新间隔不要设置的太短，重要的数据，建议30~60s，不重要的数据，≥60s；
注意：zabbix中有很多内建的item，需要的话，直接调用就可以了，并不需要每一个都要自己来手动创建；
注意：key是可以接收参数的；例如"net.if.in[ens33,packets]"，用于查看ens33网卡的收到的包的个数；
注意：在Zabbix的服务端，可以使用"zabbix_get -s 192.168.109.8 -p 10050 -k "system.cpu.intr""命令，来查看"system.cpu.intr"对应Agent上的值；
通过clone创建多个item：
注意：删除item的时候，要先清除历史数据"Clear history and trends"，然后再删除"Delete"；
注意：如果收集不到数据，可能是item定义的有错，可以通过tail /var/log/zabbix/zabbix_server.log；
（9）定义trigger：
trigger：界定某特定的item采集到的数据的非合理区间或非合理状态（逻辑表达式）
逻辑表达式，阈值；通常用于定义数据的不合理区间；
OK：主机处于正常状态 --> 较老的zabbix版本，其为FALSE；
PROBLEM：主机处于非正常状态 --> 较老的zabbix版本，其为TRUE；
OK --> PROBLEM
Recovery：PROBLEM --> OK
触发器存在可调用的函数，通过调用函数对结果进行评估：
nodata()：表示没有数据；
last()：最后几次的平均值；
date()：
time() ：
now()：
dayofmonth()：
注意：由于计算机比较擅长处理数值型的数据，不擅于处理字符型的数据，所以建议尽量的采用数值型的数据；而数值型的数据，常用的函数是nodata()、last()；
注意：此时，即便触发了触发器，并不会产生其他的操作；如果触动了触发器，还要定义action；
注意：触发器彼此之间可能存在依赖关系，例如：如果一个主机宕机了，那么该主机就采集不了数据了，假如该主机有一百个监控项，那么这一百个监控项同时报警，那么评估起来，就会很麻烦；再比如，两个主机通过交换机连接到zabbix-server，如果交换机宕机了，那么这两个主机都采集不到信息，将会同时报警，此时就会产生三个报警信息，而那两台主机并没有故障；所以，触发器之间要有依赖关系；当被依赖的触发器报警的时候，依赖他的触发器，就不会报警了；触发器可以多级依赖；
注意：触发器存在表达式：{n1.magedu.com:net.if.in[eno16777736,packets].last(#1)}>15
（10）定义action：
注意：action不属于任何主机，它属于zabbix的系统；
事件机制：
四种事件源：trigger, discovery, auto registration, internal
Media：媒介，告警信息的传递通道；
类型：Email：邮件 Script：自定义脚本 SMS：短信（国外的）
Jabber：类似于QQ，国内不可用
Ez Texting：商业工具，类似微信一样的网关
具体action内容：
当在非维护时间下，并且触动了触发器redis service down后：
执行Operations中定义的第一步，执行远程命令；
如果节点恢复正常，便会执行Recovery operations中的操作，通知管理员节点已经恢复正常；如果节点恢复失败，60s后，便会执行Operations中的第二步，通知管理员，节点出现故障，赶紧过来干活！
此时准备在zabbix-server上添加一个action，为了保证实验效果，先搭建一个实验环境，即在node1上安装redis服务，具体步骤如下：
node1节点：
yum install redis -y
cp /etc/redis.conf{,.bak}
vim /etc/redis.conf
bind 0.0.0.0
systemctl start redis
ss -tl #验证6379端口是否打开；
返回web-GUI上，配置item、trigger、action：
注意：由于定义的第一个操作是，让Agent执行用户自定义的脚本，所以需要再Host（node1）上做相关配置，具体配置如下：
visudo
zabbix ALL=(ALL) NOPASSWD:ALL
#赋予zabbix用户所有的root权限，并且不要密码；
#Defaults requiretty
vim /etc/zabbix/zabbix_agentd.conf
EnableRemoteCommands=1#允许agent执行远程命令
LogRemoteCommands=1#将远程命令记录到日志中
systemctl restart zabbix-agent
注意：Defaults requiretty：表示只能在tty下执行sudo命令，由于我们要在Agent的守护进程下执行，并没有用到终端，所以需要注释掉；如果visudo中没有该选项，可以忽略；
此时，可以在zabbix-server端，收到一封邮件：
注意：做这个实验的时候，遇到一个问题：
查看日志"tail /var/log/zabbix/zabbix_server.log -f"，他也显示：
29239:20171202:084302.892 failed to send email: cannot connect to SMTP server "localhost": bind() failed: [22] Invalid argument
解决方法：
