服务器监控系统Zabbix的自定义key、discovery、web监控图解教程（第四章）

最新推荐文章于 2023-10-02 17:06:12 发布

sigmoidhan

最新推荐文章于 2023-10-02 17:06:12 发布

阅读量4.3k

点赞数

本文链接：https://blog.csdn.net/han156/article/details/78763977

版权

（15）自定义key（User parameters）：

当我们添加监控项的时候，需要使用到zabbix中的key，不同的接口类型（数据采集信道），对应着不同的key；key其实就是zabbix Agent端告诉zabbix Server端，用来获取Agent端的某项数据所对应的符号，类似于函数名。在Agent端所要执行的具体操作，类似于函数体；

zabbix内建的key，一般用于采集硬件的信息，而如果需要采集对应的服务的信息，需要使用用户自定义的key；比如要监控nginx服务的工作状态，可以通过截取nginx的状态页，来获取数据，并将数据导入到监控项中，通过图形展示给用户；怎么指挥Agent获取用户所需要的数据，内建的key中并没有这些功能，这就用到了用户的自定义key；

自定义的key需要在zabbix_agentd.conf文件中来定义，格式如下：

UserParameter=<key>,<command>

UserParameter=<key[*]>,<command>

示例：

UserParameter=mysql.ping,mysqladmin -uroot ping|grep -c alive

注意：自定义key需要再Agent端来定义的；<key>不要和已有的key冲突，建议，做到见名知意；<command>需要用户自己编写；

注意：如果返回值是1，说明mysql处于工作状态，如果返回值是0，说明mysql处于非工作状态；由于zabbix在处理文本的时候，效率比较低，所以，建议转换成数值；

注意：由于"/etc/zabbix/zabbix_agentd.conf"配置文件中有很多的配置，所以不建议直接修改该文件，建议在"/etc/zabbix/zabbix_agentd.d"目录下创建一个*.conf文件，专门用来定义自定义key；

注意：自定义key定义结束后，需要重启zabbix-agent.service服务；

注意：定义过key之后，可以在zabbix-server端，使用zabbix_get命令来获取用户自定义的key值；

示例：

node1节点上：

vim /etc/zabbix/zabbix_agentd.d/userparameter_key.conf

UserParameter=memory.used,free -m | awk '/^Mem/{print $3}'

systemctl restart zabbix-agent.service

zabbix-server节点上：

zabbix_get -s 192.168.109.8 -p 10050 -k "memory.used"

zabbix server端：

tail /var/log/zabbix/zabbix_server.log#查看是否有报错！

zabbix agent端：

tail /var/log/zabbix/zabbix_agentd.log#查看是否有报错！

注意：此时，memory.used只能在node1节点使用，所以，当在web-GUI中配置item时，只能在node1节点使用，配置到其他的Hosts上没用。如果其他节点也想要配置此Item，需要将"UserParameter=memory.used,free -m | awk '/^Mem/{print $3}'"也在其他节点的主机上都有；

示例：使用带参数的自定义的key：

node1节点：

vim /etc/zabbix/zabbix_agentd.d/userparameter_key.conf

UserParameter=memory.stats[*],cat /proc/meminfo | awk '/^$1/{print $$2}'

systemctl restart zabbix-agent.service

zabbix server节点：

zabbix_get -s 192.168.109.8 -p 10050 -k "memory.stats[CommitLimit]"

zabbix_get -s 192.168.109.8 -p 10050 -k "memory.stats[MemFree]"

注意：$1是用户在memory.stats[]中传递的参数，$$2表示的是awk中的位置变量！如果$$2只有一个$2的话，会被认为是memory.stats[]中传递的第二个参数；

注意：实际生产中，一般使用自定义的key，需要通过状态页面，来检测服务的运行状态；大致的操作就是，在node1节点上，开启服务器的状态页面，然后通过curl命令将状态页面抓取下来，然后对需要的数据做一下处理，然后传递给Item；不过需要注意的是，状态页面的权限，尽可能的设置的小一点，即需要设置访问控制，另外不要记录key的访问日志，尽可能的减轻服务器的压力！

（16）监控发现：

在实际生产中，在监控方面，可以减轻运维工作人员的很多的工作，可是，当监控主机非常多的时候，添加新的主机，即便是有模板，组等的功能，配置起来依然会很繁琐；这样启用监控发现功能，让zabbix server自动的扫描新增的主机，并且根据主机上开启的服务，自动将其链接到模板，便可以实现对该主机的监控。

不同的主机，扮演着不同的角色，有的是Tomcat、Varnish、Nginx等等，监控项很显然是不同的，除了基础的系统级的监控项之外，如何判定其监控项呢？

可以根据IP地址，即事先定义好，不同的网段对应着不同功能的主机，当发现某段IP中新增的主机时，自动链接对应的模板；由于不同用途的主机，有其自己的属性信息；所以，也可以定义一个key，当识别出他是Nginx时，就将它关联到nginx对应的模板，当识别出Varnish时…… 所以，网络发现，可以基于以下四条信息：

IP范围；

可以获取到的服务（例如FTP、SSH、WEB、POP3、IMAP、TCP等等）；

可以根据zabbix agent提供的信息；

可以根据SNMP agent提供的信息；

所以监控发现，一般包含两个阶段，"Discovery"和"action"；就需要确定使用哪种机制来实现网络发现，并确定出是哪种用途的主机的要求，然后准备好所需要的模板，只有这样，才可以将新增的主机，自动链接至所需要的监控项上；

网络发现功能可以减轻工作人员的工作量，过于频繁的话，不但会消耗掉zabbix server很大的资源，还会损耗很大的网络资源；如果减少扫描的频率，就会有滞后性；

网络发现中添加主机时会自动创建interface，the service detected，例如，如果基于SNMP检测成功，则会创建SNMP的接口；如果某服务同时响应给了agent和SNMP，则两种接口都会创建；如果某一种发现机制（如agent）返回了非唯一数据，例如有两个ip，则第一个接口被识别为默认，其他的为额外的接口；即便是某主机开始时之后agent接口，后来又通过snmp发现了它，同样会为其添加额外的snmp接口；不同的主机，如果返回了相同的数据，则第一个主机将被添加，余下的主机会被当作第一个主机的额外接口；

实验：让node2节点，基于网络发现功能，自动添加到监控策略中，具体操作如下：