一、自动发现与自动注册
在上面的介绍中,我们演示了手动添加一台主机的方法,虽然简单,但是当要添加的主机非常多时,也将变得非常繁琐,那么有没有一种方法,可以实现主机的批量添加呢,这样就会极大的提高运维效率,答案是有的,通过zabbix提供的自动注册和自动发现功能,就可以实现主机的批量添加。

zabbix的发现包括三种类型,分别是:

 自动网络发现 ( Network discovery)
 主动客户端自动注册 ( Active agent auto-registration )
 低级别发现 ( low-level discovery )

下面依次分别进行介绍。

1.1、zabbix的自动网络发现
zabbix提供非常有力和灵活的自动网络发现功能。通过网络发现,可以实现加速zabbix部署、简化管理、在不断变化的环境中使用zabbix而不需要过多的管理

zabbix网络发现基于以下信息:

 IP段自动发现
 可用的外部服务(FTP,SSH,WEB,POP3,IMAP,TCP等等)
 从zabbix客户端接收到的信息
 从SNMP客户端接收到的信息

(1)、自动发现的原理

网络发现由两个步骤组成:发现和动作(action)。
zabbix周期性地扫描在网络发现规则中定义的IP段。根据每一个规则配置自身的检查频率。每一个规则都定义了一个对指定IP段的服务检查集合。
动作是对发现的主机进行相关设置的过程,常用的动作有添加或删除主机、启用或停用主机、添加主机到某个组中、发现通知等等。

(2)、配置网络发现规则

点击web界面的“配置”,然后选择“自动发现”,即可创建一个发现规则。如下图所示:

在这个界面中,主要设置的是“IP范围”,这里设置的是172.16.213.1到254整个213段的IP,设置了范围之后,zabbix就会自动扫描整个段的IP,那么扫描的依据是什么呢,这个需要在“检查”选项中配置,在“检查”选项中点击“新的”按钮即可出现“检查类型”选项,这里面有很多检查类型,我们就选择“zabbix客户端”即可,接着还需要输入“端口范围”和“键值”两个选项,端口就输入10050这个agent的默认端口即可,键值可以随便输入一个zabbix默认键值即可,这里输入的是“system.uname”,然后点击下面的“添加”按钮即可,这样一个自动发现规则就创建完成了。

综上所述,这个字段发现规则的意思是:zabbix会自动扫描172.16.213.1到254这个段的所有IP,依次连接这些IP的10050端口,接着通过“system.uname”键值看是否能获取数据,如果能获取到数据,那么就把这个主机加入到自动发现规则中。

自动发现规则添加完成后,接着,就可以添加自动发现动作了,点击web界面的“配置”,然后选择“动作”,在右上角事件源选择“自动发现”,接着点击“创建动作”按钮,即可创建一个自动发现的动作,如下图所示:

在自动发现动作配置界面中,难点是设置自动发现的条件,“计算方式”选择默认的“与/或(默认)”即可,要添加触发条件,可以在“新的触发条件”选项下选择触发条件,触发条件有非常多,这里选择红框内的四个即可,选择完成后,点击“添加”就把选择的触发条件添加到了上面的“条件”选项中。

除了自动发现条件的设置,还需要设置自动发现后操作的方式,点击上图中的“操作”链接,进入下图设置界面:

此界面是设置自动发现主机后,要执行哪些操作,这里重点是设置操作的细节,点击左下角的“新的”按钮可以设置多个操作动作,一般情况下设置四个即可,也就是发现主机后,首选自动将这个主机添加到zabbix web上来,然后将“Linux servers”主机组和“Template OS Linux”模板也自动链接到此主机下。最后在zabbix web中启用这个主机。

经过三个步骤的操作,zabbix的自动发现配置就完成了,稍等片刻,就会有符合条件的主机自动添加到zabbix web中来。

1.2、主动客户端自动注册
自动注册(agent auto-registration)功能主要用于Agent主动且自动向Server注册。与前面的Network discovery具有同样的功能,但是这个功能更适用于特定的环境,当存在一个条件未知(如agent端的IP地址段、agent端的操作系统版本等信息)时,Agent去请求Server仍然可以实现主机自动添加到zabbix web中的功能。比如云环境下的监控,云环境中,IP分配就是随机的,这个功能就可以很好的解决类似的问题。

配置主动客户端自动注册有两个步骤,分别是:

 在客户端配置文件中设置参数
 在zabbix web中配置一个动作(action)

(1)、客户端修改配置文件

打开客户端配置文件zabbix_agentd.conf,修改如下配置:

Server=172.16.213.231
ServerActive=172.16.213.231   #这里是主动模式下zabbix服务器的地址
Hostname=elk_172.16.213.71 
HostMetadata=linux zabbix.alibaba   #这里设置了两个元数据,一个是告诉自己是linux服务器,另一个就是写一个通用的带有公司标识的字符串。

自动注册请求发生在每次客户端发送一个刷新主动检查请求到服务器时。请求的延时在客户端中配置文件zabbix_agentd.conf的RefreshActiveChecks 参数中指定。第一次请求将在客户端重启之后立即发送。

(2)、配置网络自动注册规则

点击web界面的“配置”,然后选择“动作”,在右上角事件源选择“自动注册”,接着点击“创建动作”按钮,即可创建一个自动注册的动作,如下图所示:

在自动注册动作配置界面中,难点是设置自动注册的条件,“计算方式”选择默认的“与/或(默认)”即可,要添加触发条件,可以在“新的触发条件”选项下选择触发条件,触发条件有非常多,这里选择红框内的两个即可,这两个条件其实都是在zabbix agent端手工配置上去的,选择完成后,点击“添加”就把选择的触发条件添加到了上面的“条件”选项中。

除了自动注册条件的设置,还需要设置自动注册后操作的方式,点击上图中的“操作”链接,进入下图设置界面:

此界面是设置自动注册主机后,要执行哪些操作,这里重点是设置操作的细节,点击左下角的“新的”按钮可以设置多个操作动作,一般情况下设置四个即可,也就是发现主机后,首选自动将这个主机添加到zabbix web上来,然后将“Discovered hosts”主机组和“Template OS Linux”模板也自动链接到此主机下。最后在zabbix web中启用这个主机。

经过两个步骤的操作,zabbix的自动注册配置就完成了,稍等片刻,就会有符合条件的主机自动添加到zabbix web中来。

1.3、低级别发现Low-level discovery(LLD)
在对主机的监控中,可能出现这样的情况,例如对某主机网卡eth0进行监控,可以指定需要监控的网卡是eth0,而将网卡作为一个通用监控项时,根据主机操作系统的不同,网卡的名称也不完全相同,有些操作系统的网卡名称是eth开头的,而有些网卡名称是em开头的,还有些网卡是enps0开头的,遇到这种情况,如果分别针对不同的网卡名设置不同的监控项,那就太繁琐了,此时使用zabbix的低级发现功能就可以解决这个问题。

在Zabbix中,支持三种现成的类型的数据项发现,分别是:

 文件系统发现
 网络接口发现
 SNMP OID发现
 CPU核和状态

下面是zabbix自带的LLD key,

 vfs.fs.discovery #适用于zabbix agent监控方式
 snmp.discovery #SNMP agent监控方式
 net.if.discovery #适用于zabbix agent监控方式
 system.cpu.discovery #适用于zabbix agent监控方式

可以用zabbix-get来查看key获取的数据,对于snmp,不能通过zabbix-get来验证,只能在web页面中进行配置使用。

下面是zabbix-get的一个例子:

[root@localhost ~]#/usr/local/zabbix/bin/zabbix_get  -s 172.16.213.232 -k net.if.discovery
{"data":[{"{#IFNAME}":"eth0"},{"{#IFNAME}":"lo"},{"{#IFNAME}":"virbr0-nic"},{"{#IFNAME}":"virbr0"}]}

其中,{#IFNAME}就是一个宏变量,会返回系统中所有网卡的名字。宏变量可以定义在主机、模板以及全局,宏变量都是大写的。使用宏变量,可以使zabbix功能更加强大。

在自动发现中使用zabbix自带的宏,固定的语法格式为:

{#MACRO}

zabbix还支持用户自定义的宏,这些自定义的宏也有特定的语法:

{$MACRO}

在LLD中,常用的内置宏有{#FSNAME}, {#FSTYPE}, {#IFNAME}, {#SNMPINDEX}, {#SNMPVALUE}等。其中,{#FSNAME}表示文件系统名称,{#FSTYPE}表示文件系统类型,{#IFNAME}表示网卡名称,{#SNMPINDEX}会获取OID中最后一个值;例如:

# snmpwalk -v 2c -c public 10.10.10.109 1.3.6.1.4.1.674.10892.5.5.1.20.130.4.1.2  
SNMPv2-SMI::enterprises.674.10892.5.5.1.20.130.4.1.2.1 = STRING: "Physical Disk 0:1:0"
SNMPv2-SMI::enterprises.674.10892.5.5.1.20.130.4.1.2.2 = STRING: "Physical Disk 0:1:1"
SNMPv2-SMI::enterprises.674.10892.5.5.1.20.130.4.1.2.3 = STRING: "Physical Disk 0:1:2"

那么, {#SNMPINDEX}, {#SNMPVALUE}获取到的值为:

{#SNMPINDEX} -> 1,{#SNMPVALUE} -> "Physical Disk 0:1:0"
{#SNMPINDEX} -> 2,{#SNMPVALUE} -> "Physical Disk 0:1:1"
{#SNMPINDEX} -> 3,{#SNMPVALUE} -> "Physical Disk 0:1:2"

宏的级别有多种:其优先级由高到低顺序如下:

 主机级别的宏优先级最高
 第一级模板中的宏
 第二级模板中的宏
 全局级别的宏

因此,zabbix查找宏的顺序为:首选查找主机级别的宏,如果在主机级别不存在宏设置,那么zabbix就会去模板中看是否设置有宏。如果模板中也没有,将会查找使用全局的宏。若是在各级别都没找到宏,将不使用宏。

二、zabbix自定义监控项
有时候当我们监控的项目在zabbix预定义的key中没有定义时,这时候我们可以通过编写zabbix的用户参数的方法来监控我们要求的项目item。形象一点说zabbix代理端配置文件中的User parameters就相当于通过脚本获取要监控的值,然后把相关的脚本或者命令写入到配置文件中的User parameter中,然后zabbix server读取配置文件中的返回值通过处理前端的方式返回给用户。

2.1、zabbix agent端开启Userparameter指令
在zabbix_agent.conf文件中开启如下参数:

UnsafeUserParameters=1

启用agent端自定义item功能,设置此参数为1后,就可以使用UserParameter指令了。

UserParameter用于自定义itme。语法格式为:

UserParameter=<key>,<command>

其中:

UserParameter为关键字
key为用户自定义key名字可以随便起
为我们要运行的命令或者脚本。

一个简单的例子:

UserParameter=ping,echo 1

代理程序程序将会永远的返回1当我们在服务器端添加item的key为 ping时候。

稍微复杂的例子:

UserParameter=mysql.ping, /usr/local/mysql/bin/mysqladmin ping|grep -c alive

当我们执行mysqladmin -uroot ping命令的时候如果mysq存活要返回mysqld is alive,我们通过grep–c来计算mysqld is alive的个数,如果mysql存活着,则个数为1,如果不存活很,明显mysqld is alive的个数为0,通过这种方法我们可以来判断mysql的存活状态。

当我们在服务器端添加item的key为mysql.ping时候,对于zabbix代理程序,如果mysql存活,则状态将返回1,否则,状态将返回0。

2.2、让key接受参数
让key也接受参数的方法使item添加时更具备了灵活性,例如,系统预定义key :

vm.memory.size[<mode>]

其中的mode模式就是用户要接受的参数,当我们填写为free时则返回的为内存的剩余大小,如果我们填入的为userd时返回的是内存已经使用的大小。

相关语法如下:

UserParameter=key[*],command

其中,Key的值在主机系统中必须是唯一的,其中*代表命令中接受的参数,command表示命令,也就是客户端系统中可执行的命令

看下面一个例子:

UserParameter=ping[*],echo $1

如果执行ping[0],那么将一直返回 ‘0’,如果执行ping[aaa],将一直返回 ‘aaa’

三、zabbix的主动模式与被动模式
默认情况下,zabbix server会直接去每个agent上抓取数据,这对于zabbix agent来说,是被动模式,也是默认的一种获取数据的方式,但是,当zabbix server监控主机数量过多的时候,由Zabbix Server端去抓取agent上的数据,Zabbix server会出现严重的性能问题,主要表现如下:

 Web操作很卡,容易出现502错误
 监控图形中图层断裂
 监控告警不及时

所以下面主要从两个方面进行优化,分别是:

 通过部署多个zabbix Proxy模式做分布式监控
 调整Zabbix Agentd为主动模式

Zabbix Agentd主动模式的含义是Agentd端主动汇报自己收集到的数据给Zabbix Server,这样,Zabbix Server就会空闲很多,下面介绍下如何开启agent的主动模式。

3.1、zabbix Agentd配置调整
修改zabbix_agentd.conf配置文件,主要是如下三个参数:

ServerActive=172.16.213.231
Hostname=172.16.213.232
StartAgents=1

ServerActive是指定Agentd收集的数据往哪里发送,Hostname必须要和zabbix web端添加主机时的主机名对应起来,这样zabbix Server端接收到数据才能找到对应关系,StartAgents默认为3,要关闭被动模式,可设置StartAgents为0即可,关闭被动模式后,agent端的10050端口也关闭了,这里为了兼容被动模式,没有把StartAgents设为0,如果一开始就是使用主动模式的话,建议把StartAgents设为0,关闭被动模式。

3.2、Zabbix Server端配置调整
如果开启了agent端的主动发送数据模式,还需要在zabbix Server端修改如下两个参数,保证性能。

StartPollers=10  #把这个zabbix Server主动收集数据进程减少一些。
StartTrappers=200  #把这个负责处理Agentd推送过来数据的进程开大一些。

3.3、调整模板
因为收集数据的模式发生了变化,因此还需要把所有的监控项的监控类型由原来的“zabbix客户端”改成“zabbix客户端(主动式)”。

这样经过三个步骤的操作,就完成了主动模式的切换,调整之后,可以观察zabbix server的负载,应该会降低不少,在操作上,服务器也不卡了,图层也不裂了,zabbix的性能问题解决了。

文档更新时间: 2018-12-08 12:29   作者:李延召