一、zabbix-server添加被监控主机
1、Node1节点安装zabbix-agent,zabbix-sender并修改配置文件
[root@Node1 ~]# yum install zabbix-agent zabbix-sender
Dependencies Resolved
===================================================================================================================================
Package Arch Version Repository Size
===================================================================================================================================
Installing:
zabbix-agent x86_64 2.4.8-1.el6 Zabbix 175 k
zabbix-sender x86_64 2.4.8-1.el6 Zabbix 66 k
Installing for dependencies:
zabbix x86_64 2.4.8-1.el6 Zabbix 165 k
Transaction Summary
===================================================================================================================================
Install 3 Package(s)修改配置文件
[root@Node1 zabbix]# grep -v '^#\|^$' zabbix_agentd.conf #修改后
PidFile=/var/run/zabbix/zabbix_agentd.pid
LogFile=/var/log/zabbix/zabbix_agentd.log
LogFileSize=0
Server=192.168.10.2
ServerActive=192.168.10.1
Hostname=Node1
Include=/etc/zabbix/zabbix_agentd.d/启动zabbix-agent:
[root@Node1 zabbix]# service zabbix-agent start
Starting Zabbix agent: [ OK ]
[root@Node1 zabbix]# netstat -nlptu|grep zabbix
tcp 0 0 0.0.0.0:10050 0.0.0.0:* LISTEN 3352/zabbix_agentd
tcp 0 0 :::10050 :::* LISTEN 3352/zabbix_agentd
2、zabbix-server添加被监控主机Node1
点击configuration -->hosts-->Create host 填上相应信息即可
添加完成后:
host name:必须是唯一的,用来标识主机的地址,必须要和agent配置文件中填写的host name保持一致。否则会报错,
查看监控机上的/var/log/zabbix/zabbix_server.log,
显示日志:
cannot send list of active checks to [192.168.0.1]: host [Zabbix server] not found
查看被监控机上的/var/log/zabbix/zabbix_agentd.log,
显示日志:
No active checks on server: host [Zabbix server] not found
这是因为,通过zabbix dashboard页面配置的被监控主机名跟被监控主机上zabbix_agentd.conf中配置的Hostname不一致。
修改为一致的名字后,重启zabbix_agentd即可。visible name:在zabbix中显示的名字
二、添加监控项
1、监控项(item)
“ 监控项(item)”是Zabbix 服务器用于监控一个特定对象上的一个特定指标,并负责针对其收集相关的监控数据
比如CPU每分钟的平均负载可以是一个item,每5分钟的平均负载是一个item,某特定网络接口接收报文的速率又是一个item等
每一个Item都拥有相应的“类型(Type)”
例如“Zabbix agent”、“SNMP”、“External check”、“IPMI agent”、“SSH agent”、“JMX agent”等
Zabbix服务器会使用相应类型的协议或机制同被监控端通信
2、主要属性介绍
Host:选择新建的item所属的主机或模板;默认为点击“item”时所属的主机或模板;
Name:item的名称,可以使用宏$1、$2、……、$9,用于引用相应Key中的对应的参数;
例如,名称“CPU $2 time”对于system.cpu.util[,iowait]来说,其名称为“CPU iowait time”;
Type:item类型;
Key:当前item的key,每个item所支持使用的key取决于所选择的“Type”;对一个主机来讲,每个key必须是惟一的;如果Type为“Zabbix agent”, “Zabbix agent (active)”,“Simple check”或者“Zabbix aggregate”,其Key值必须要被Zabbix agent及Zabbix Server支持才行;
Update interval (in sec):获取数据的时间间隔,0表示不去拉取数据;
Flexible intervals:自定义数据更新时间间隔,例如Interval (in sec)为10,Period值为6-7,00:24:00表示周六和周日全天每10秒钟获取一次数据;
Keep history (in days) :历史数据保留时长,单位为天;超过此时长的数据都会由Housekeeper清除;一般来说,仅需要保留所需要的时间跨度的最小天数内的数据;
Keep trends (in days):聚合(趋势)数据(如min、max、avg、count等数据)的保留时长,单位为天;超过此时长的数据都会由Housekeeper清除;
Store value:
As is:不做任何处理;
Delta (speed per second):保存为(value-prev_value)/(timeprev_time)的计算结果,即当前值减去前一次获取的数据值,除以当前时间戳减去前一次值获取时的时间戳得到的结果;如果当前值小于前一次的值,其将会被丢弃;
Delta (simple change):保存为 (value-prev_value)的计算结果;
Status:
Enabled:启用;
Disabled:禁用;
Not supported:不支持
3、item key
每一个item都有其专用的“Key”
Zabbix服务器在与被监控端通信时就使用相应的协议或机制去询问被监控端这个Key的值,被监控端则调用与此Key对应的监控脚本获取数据并返回给服务器端
Key的命名只能使用“0-9a-zA-Z_-.”(引号中的内容)等字符,且可以接受参数,
其命令习惯如system.cpu.load[,],其中,中括号中的内容为参数,且分别可以按次序使用$1、$2、…进行引用,此示例中仅有两个参数,若要使用不定数目的参数,则可以使用“*”表示
注意:每个key背后都应该有一个命令或脚本来负责数据收集,此命令或脚本可调用传递给key的参数,调用方式为$1,$2...
zabbix有许多预定义的key,详细信息的获取地址:
https://www.zabbix.com/documentation/2.0/manual/config/items/itemtypes/zabbix_agent
对于每一个item,Zabbix服务器还定义了怎么存储这个item的数据以、数据采集的频率及历史数据的保存时长等
多个item还可归类为一个由“application”定义的逻辑组
4、获取item key的值
[root@Node2 ~]# rpm -ql zabbix-get
/usr/bin/zabbix_get
/usr/share/man/man1/zabbix_get.1.gz
[root@Node2 ~]# zabbix_get --help
Zabbix get v2.4.8 (revision 59539) (20 April 2016)
usage: zabbix_get [-hV] -s [-p ] [-I ] -k
Options:
-s --host Specify host name or IP address of a host
-p --port Specify port number of agent running on the host. Default is 10050
-I --source-address Specify source IP address
-k --key Specify key of item to retrieve value for
-h --help Display help information
-V --version Display version number
Example: zabbix_get -s 127.0.0.1 -p 10050 -k "system.cpu.load[all,avg1]"
[root@Node2 ~]# zabbix_get -s 192.168.10.1 -k "system.uname"
Linux Node1 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64
历史数据:过去每次采样生成的数据
历史趋势数据:每小时的最大值,最小值,平均值统计
As is:不做任何处理
Delta(差量)(speed per second): (value - pre_value)/(time-pre_time)
Delta(simple chang):(value-pre_value)
三、添加触发器
1、触发器(trigger)
“监控项”仅负责收集数据,而通常收集数据的目的还包括在某指标对应的数据超出合理范围时给相关人员发送告警信息, “触发器”正是用于为监控项所收集的数据定义阈值
每一个触发器仅能关联至一个监控项,但可以为一个监控项同时使用多个触发器;事实上,为一个监控项定义多个具有不同阈值的触发器,可以实现不同级别的报警功能
一个触发器由一个表达式构成,它定义了监控项所采取的数据的一个阈值
一旦某次采集的数据超出了此触发器定义的阈值,触发器状态将会转换为“Problem”;而当采取的数据再次回归至合理范围内时,其状态将重新返回到“OK”
2、触发器表达式
触发器表达式高度灵活,可以以之创建出非常复杂的测试条件
基本的触发器表达式格式如下所示:
{:.()}
表达式,如:>,3
表示主机www.magedu.com上所有CPU的过去1分钟内的平均负载的最后一次取值大于3时将触发状态变换
对last函数来说,last(0)相当于last(#1)
3、触发器间的依赖关系
在一个网络中,主机的可用性之间可能存在依赖关系
例如,当某网关主机不可用时,其背后的所有主机都将无法正常访问
如果所有主机都配置了触发器并定义了相关的通知功能,相关人员将会接收到许多告警信息,这既不利于快速定位问题,也会浪费资源
正确定义的触发器依赖关系可以避免类似情况的发生,它将使用通知机制仅发送最根本问题相关的告警
注意:目前zabbix不能够直接定义主机间的依赖关系,其依赖关系仅能通过触发器来定义
4、触发器等级
unknown severity 未知的严重性 灰色
for information purposes 供参考 亮绿灯
average 常见问题 橙色
disaster 灾难
5、创建触发器
创建触发器可用的各属性说明
Name:触发器名称,可以使用宏,如$1、$2、……、$9等;
Expression:逻辑表达式,用于评估触发器状态;
Multiple PROBLEM events generation:依赖于当前触发器的“Problem”状态生成其它事件;
Description:当前触发器的描述信息;
URL:在screen的“Status of Trigger”中显示的内容的链接;
Severity:当前触发器的严重级别;
Enabled:是否启用当前触发器;
四、执行动作(action)和事件(event)
1、action
message 通知的内容
condition 触发条件
operation 操作
send message
media 服务器和发件人
user 收件人
remote comman
(1) 给zabbix定义sudo规则:
zabbix ALL=(ALL) NOPASSWD: ALL
#Defaults requiretty #注释掉执行sudo命令要求通过安全tty才能执行, (2)不支持(active)主动模式的agent,就是说自动注册的客户端不支持
(3)不支持代理模式
(4)命令长度不得超过255字符
(5)可以使用宏
(6)zabbix-server仅执行命令,而不关心命令是否执行成功
前提:
zabbix-agent要配置为支持执行远程命令:
在客户端修改配置文件/etc/zabbix/zabbix_agentd.conf
EnableRemoteCommands=1
LogRemoteCommands=1 命令如果用到以其它用户身份执行时,命令本身要以sudo执行:sudo /etc/rc.d/init.d/httpd restart
在配置好监控项和触发器之后,一旦正常工作中的某触发器状态发生改变,一般意味着有异常情况发生,此时通常需要采取一定的动作(action),如告警或者执行远程命令等
并非所有的触发器状态发生改变的场景都需要对其进行干预,如转变为“OK”状态时,相应地,如果触发器的状态转变为“Problem”,就需要告知所有关心其相关监控指标的人员了。
1)“通知(notification)”是zabbix中最常用的“动作”之一
实现zabbix的通知功能,一般需要两个步骤:
定义所需的“媒介(media)”:通常指发送信息的途径,如邮件、Jabber和SMS等;
配置一个“动作(action)”:发送信息至某“媒介”;
动作由“条件”和“操作”组成,它的逻辑为当“条件”满足时,就执行相应的“操作”
“发送通知”和“执行远程命令”是两个最基本的操作
2)“remote comman”
2、event
Zabbix的事件是基于时间戳进行标记的,它们是采取动作(action)如发送邮件通知的基础,其主要来源于三种途径
触发器(trigger)事件:触发器状态每次发生改变,都会生成相应“事件”,且通常包含详细信息,如发生的时间及新的状态等;
发现(discovery)事件:zabbix会周期性地扫描“网络发现规则”中指定的IP范围,一旦发现主机或服务,就会生成一个或几个发现事件;
发现事件有8类:Service Up、Service Down、Host Up、Host Down、Service Discovered、Service Lost、Host Discovered和Host Lost;
主动agent自动发现事件(也称作“自动注册事件”):当一个此前状态未知的主动agent发起检测请求时会生成此类事件;
Internal events:Item变成不再支持或trigger变成未知状态
lld
因此,Zabbix的通知机制也称作基于事件的通知机制,也只有理解了事件本身,才能定制出符合需求的通知系统
3、 媒介类型 (Media type)
在zabbix中,媒介指发送通知信息的通道,其通常有以下几种类型
E-mail: 电子邮件,即通知邮件的方式传送通知信息;
SMS:手机短信,即通过连接至zabbix服务器GSM Modem发送通知;
Jabber:jabber消息;Jabber是一个开放的、基于XML的协议,能够实现基于Internet或LAN的即时通讯服务;
自定义的通知脚本: 以上方式不能满足需求时,zabbix可以调用位于其配置文件/etc/zabbix/zabbix_server.conf “AlertScriptsPath”变量所定义的脚本查找目录中的脚本来完成通知功能;
脚本中可使用$1,$2,$3来调用action中的邮件的收件人,Default subject(主题), default message(内容)
[root@Node2 ~]# cd /usr/lib/zabbix/alertscripts/
[root@Node2 alertscripts]# ls
alerttest.sh
[root@Node2 alertscripts]# cat alerttest.sh
#!/bin/bash
#
echo "$3"|mail -s "$2" "$1"
五、定义报警的步骤
定义示警媒体(服务器和发件人)-->创建通知信息接受者(收件人)-->创建动作(内容)
1、定义示警媒体
2、定义通知信息接受者
SMTP server:SMTP服务器
SMTP helo:SMTP helo值,通常情况下是顶级域名。SMTP服务器间需要交换数据时,先会探测对发是否在线
SMTP email:发件人
3、创建动作
action主要属性的说明:
Name:当前action的独有名称;
Default operation step duration:默认每一级“告警升级“的周期;
Default subject:默认的消息主题,可以使用宏;
Default message:默认的消息,可以包含宏;
Recovery:监控项从“问题”状态恢复之后是否发送的消息;如果启用,恢复消息仅发送给监控项转换为“问题”状态时的通知对象;
Recovery subject:恢复消息主题,可以包含宏;
Recovery message:恢复消息,可以包含宏;
Enabled:是否启用当前action;
Action的操作(operation):
zabbix支持的操作有两类:“发送通知”和“执行远程命令”
而对于“发现”类事件来说,其支持的操作还有添加主机、移除主机、启用主机、禁用主机、添加到组、从组中删除、链接到模板及从模板上拆除关联等
对于“自动注册”类事件来说,支持的操作为添加主机、禁用主机、添加到组及链接至模板等
Operation相关的属性说明:
Step:告警升级(escalation)调度方式;
From:操作开始的位置;即第几次升级间隔时间到达后检测仍然有“问题”时开始执行操作;
To:直到哪一步为止,其减去From中的数字再加1即表示要操作的次序;0表示无限;
Step duration:前述自定义告警升级的时间间隔,0表示使用默认;
Operation type:操作类别;选定不同的操作类别,其后续的其它属性也有所不同;
Send message:发送消息;
Remote command:执行远程命令;
Conditions:执行操作的条件;
Not ack:仅在事件为“未知(unacknowledged)”时执行操作;
Ack:仅在事件可被识别(acknowledged)时执行操作;
类别为“Send message”时的相关属性:
Send to User groups:给选定组中的所有用户发送通知;
Send to users:给选定的用户发送通知;
Send only to:发送通知时所使用的媒介,all为所有媒介;
Default message:如果启用,则发送默认消息;
Subject:消息的自定义主题,可以包含宏;
Message:要发送的消息内容,可以使用宏;
类别为“remote command”时的相关属性:
Target list:远程命令执行的目标主机,可以是当前主机、其它主机或主机组;
Type:命令类型;
IPMI:IPMI命令;
Custom script:自定义脚本,可以选择其是在zabbix server上还是zabbix agent上执行;
SSH: 通过ssh执行命令,需要提供目标主机上的用户帐号、相关的认证方式及认证所需要额外信息;
Telnet:通过telnet执行命令,需要指定用户名、口令及远程主机telnet服务监听的端口;
Global script:全局脚本,执行“Administration→Scripts”定义的脚本的其中之一;
Commands:要执行的命令;
告警升级(escalation)
escalation用于实现用于定制发送通知或执行远程命令的方式,
常用于实现如下场景:
出现问题时立即发送通知;
问题得不到解决时多次发送通知给用户;
按需延迟发送通知;
问题长久得不到解决时发送给级别更高的用户;
立即执行远程命令或经过一个预定的时长后仍未解决问题时执行远程命令;
故障恢复时发送相关信息;
实际操作中,action的escalation机制的实现依赖于“escalation step(升级步长)”,step是一个时间长度;
为了简化操作过程,可以为step定义默认的时长,只有在必要时才为action自定义其step
可以在任何有效的step到达时启动action,第1个step表示立即启动;
如果要延迟启动action,可以选择在后面的其它step上启动
下面示例表示延迟一个step之后才启用action
Zabbix完整的监控配置流程大体上由如下步骤组成:
host group --> hosts -->Applications -->items(存储mysql) -->graph(zabbix-web)-->triggers(ok-->problem)-->events -->actions --> User groups --> Medias -->Users
运维网声明
1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网 享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com