服务器监控系统Zabbix的host、Item、trigger、action图解教程(第二章)

xiaoxiao2021-02-28  4

(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

解决方法:

转载请注明原文地址: https://www.6miu.com/read-1400377.html

最新回复(0)