Zabbix监控流程详解（自己的心得）

本篇主要是我最近使用zabbix3.2的一些理解，参考官方文档https://www.zabbix.com/documentation/3.2/manual

先抛开zabbix监控的其他架构不谈，从最简单的server-agent模式说起，即监控主机-被监控主机（主动模式、被动模式主要是影响数据的采集方式和服务端的负载压力），首先是zabbix最重要的五个组成部分：Item、Trigger、Action、Media、User（其实应该还有个Event，不过这个表现的不直观），翻译一下就是监控元素、触发器、动作、报警介质、用户，接下来一个一个的详谈，最后在梳理他们之间的关系。

Item，官方说明为Items are the ones that gather data from a host. 意思就是监控采集的项目，举个栗子就是agent端的cpu、内存等，但是更加具体的来说，比如说cpu使用率，或者是cpu某个核的使用率或者是cpu的空闲率，item应该是这样一个十分具体的项，而item是由key+参数组成，在定制化的监控项中，key比较好理解，举个实际的例子比较直观，在server端创建item，name填test，type选择zabbix agent，key填写echo，返回数据类型选int，然后在agent.conf文件中，找到UserParameter行，按如下格式   UserParameter=<key>,<command>，具体我们写为UserParameter=echo,echo 1    然后重启zabbix服务，在“最近数据”选项卡中可以看到test值为1，可以看到我们新设置的item “test”是根据key值来执行响应命令并返回值，那我们就可以在“command”那里使用一些命令来拿到我们需要监控的值（比如用top命令再grep一下再awk处理一下得到cpu、内存的值之类的），甚至可以在这里写一个脚本执行语句，然后在对应位置写好脚本，值得注意的一点是key后面可以接参数，比如UserParameter=echo[a],echo $1 这个跟shell的参数传递一样的，讲到这里是不是比较理解key和item的关系了呢，但是这里item是由key+参数组成的还不明显，我们再用官方给的item举个实例。

https://www.zabbix.com/documentation/3.2/manual/config/items/itemtypes/zabbix_agent 这是官方给出的监控item项，由windows、linux、AIX等等的监控项，注意要对应上，使用官方item的时候就不用在conf文件里增加UserParameter了，因为都内置好了，只要在创建item时注意填写参数即可，以监控日志为例，

选择创建item，名字随便填，只是key这里需要注意，[]中有7个参数，没有<>的是必填的，其余选填，参数意义官方文档中都有说明，参数可以为空，表示使用默认值，比如log[/var/log/syslog，error]，官方说明若output项为空，则输出匹配文本的整行，即包含“error”的行。

可见参数对我们监控项的重要性，对于item暂时就说这么多，有问题的多看官方文档。

Trigger

顾名思义触发器，也就是将采集来的item值进行一定的判断，需要注意的点有两个，一个是serverity，即报警等级，还有一个是判断的逻辑，判断逻辑分单机判断和触发依赖，，在此设置触发依赖，官方文档有个很典型的例子，

，

就是说假如有这样一个网络关系：

Zabbix  -  Router1  -  Router2  - 主机

主机关机触发的条件为router2触发，而router2触发的条件为router1触发，因为route1出问题的时候，明显router2和主机网络都不可达，但是此时并不想收到三份告警，就可以设置这样一个依赖关系。

普通的触发器设置就比较简单了，大概是这样一个表达式

{<server>:<key>.<function>(<parameter>)}<operator><constant>

花括号中间的内容是item采集回来的参数，而右边是一个做逻辑判断的式子，比如

{www.zabbix.com:system.cpu.load[all,avg1].last()}>5

主机部分比较容易明白，而key呢最好是参考官方文档里给出key，里面有参数很丰富，'.'后面接的是一个函数及函数的参数，last函数就是最新的一次数据，还有很多函数像sum()、min()、count()等等，后面的判断也比较常见，‘>’‘=’‘<>’等等，需要详细了解的还是看我最上面发的官方文档连接，然后这一个逻辑判断就完成了，有时候还需要多个判断，这时候就只需要用'or''and'等连接几个这样相同格式的判断语句即可。

Action

action就是server对事件响应（Event）需要做相应的措施了，关键点是四个，一是如何触发action，而是action具体使用什么方式，三是发送的内容，四是动作的对象。action支持的Event有四种：用大白话讲就是Trigger触发时、discover rule文件生效时、自动发现新服务器时以及server本身出问题时。最主要的就是Trigger触发来产生action，在创建action时会有"condition"这个选项来设置触发器，而action的方式是由media来决定，media有五种，常见的是mail、sms、script这三种，邮件的方式只需要在创建一个media方式选邮件，然后填写smtp服务器地址即可，邮件的内容是在action选项卡里面设置，支持普通的字符串以及表达式比如{TRIGGER.NAME}这种，这个值就是对应触发的Trigger的名字，同时这些信息也会存入数据库，在alerts表单里面，sms我没用过应该和邮件差不多，重点讲下执行脚本，在zabbix_server.conf文件里会配置执行脚本的路径，一般默认为zabbix目录/share/alertscripts,当然这个路径你可以随便改，只要在这个路径下创建脚本即可，条件满足后就会执行这个脚本，action这块的整个配置流程是：1.选择触发器的条件  2.填写发送的内容  3.选择事件发送的用户以及方式（media） 4.到用户选项卡，在media里配置信息    

Action、Media、User这几者的关系我梳理一下，是action将产生的信息发送给user，然后user选择相应的media进行处理，而产生的信息呢不进行调用只会存在数据库里，或者在报表选项卡里的action log里可以看到，发送给用户的信息在使用mail报警时就直接吧action里设置的内容发送过去，但脚本方式就没太大联系了，比如在脚本调用时你需要把这次的告警信息存到一个文件里， .sh文件里写 mysql -u用户 -p密码 -e "use zabbix; select * from alerts\G;" >> /var/test.log 这个是把数据库里的信息给导出来，并不是action的内容直接用，不过本身action里面设置的内容也是存在数据库里，当然调用数据库的信息还可以更完整，alerts里面还有存放event id、时间、发送ip等等其他信息，看你的脚本怎么写了。  

其实action里面还可以执行远程命令，用于服务重启之类的，比如httpd报警了，就直接远程命令执行servicce restart之类的，有兴趣的可以自行研究

这里附一张图（一本书里的），报警流程感觉说的比较清楚了，我也是才学zabbix没多久，感觉很多东西还是得自己配置做做小实验对报警的流程印象会比较深，还有就是个人感觉看官方文档是真的很有用，很多东西都写得很清楚，希望我没说明白的地方能看官方文档在理解理解，共勉。