189 8069 5689
通过前面章节的学习，你会发现Zabbix是一个非常灵活、功能强大的监控系统，但是在实际环境中配置好Zabbix是一个非常繁重的工作。所幸的是Zabbix提供了一些工具，能够让Zabbix自动化的完成任务，让运维工作变的轻松。
克井网站制作公司哪家好，找创新互联建站！从网页设计、网站建设、微信开发、APP开发、自适应网站建设等网站项目制作，到程序开发，运营维护。创新互联建站于2013年开始到现在10年的时间，我们拥有了丰富的建站经验和运维经验，来保证我们的工作的顺利进行。专注于网站建设就选创新互联建站。
Zabbix的自动化工具主要有networkdiscovery（网络发现）、active agentauto-registration（主动式代理自动注册）和 Low-leveldiscovery（低级发现）。
Zabbix中网络发现由两部分组成：discovery（发现）和actions（动作），首先通过定期扫描网络，按照预先定义的规则搜索网络中的服务器或设备。当发现符合条件的服务器或设备时生成发现事件，然后结合我们定义的基于发现事件的动作，发现并添加/删除主机和其他一些简单的管理，依照网络环境快速的搭建监控系统。这些动作包括：
创建或删除主机。
启用或禁用主机。
添加主机到主机组。
从主机组中删除。
链接模板到主机或取消链接的模板。
发送通知。
执行远程命令。
在指定的IP地址范围中，Zabbix使用下列三种方法检测网络中的服务器或设备：
从Zabbix agent接收的信息（不支持加密模式）。
从SNMP agent接收的信息。
基于服务（FTP、SSH、WEB、POP3、IMAP、TCP等）的可用性。
每一次完成一个主机（IP）和服务的检测时，网络发现会生成一个发现事件。可生成事件的列表如下：
Service Discovered：第一次发现或者服务的状态以前是down，现在的状态是up。
Service Up：服务的状态一直是up。
Service Lost：服务的状态以前是up，现在的状态是down。
Service Down：服务的状态一直是down。
Host Discovered：主机上所有服务以前的状态是down，现在至少有一个服务的状态是up。
Host Up：主机上至少有一个服务的状态一直是up。
Host Lost：主机以前至少有一个服务的状态是up，现在所有服务的状态是down。
Host Down：主机上所有服务的状态一直是down。
如果在动作中选择了Add host操作，新发现的主机会自动创建，同时还可以在动作中定义下列操作：
允许主机
禁用主机
添加主机到主机组
链接模板到主机
创建主机时，主机名称以Zabbix server或proxy server进行DNS反向查询的结果命名，如果反向查询失败则用IP地址命名。反向查询失败后是否重试取决于discovery在哪里执行，在proxyserver上查询失败后不再重试。
新创建的主机名称在Zabbix server中已经存在时，新创建主机的名称会在名称后面添加_2表示第二个重名的主机，_3表示第三个重名的主机，以此类推。
新创建的主机默认添加到Discovered hosts group主机组中，这个默认值是在Administration--> General --> Other页面中的Group fordiscovered hosts参数中配置的。如果你希望主机添加到其他主机组中，需要在动作的操作中添加 Remove from host groups（指定Discovered hosts），同时添加Add tohost groups（指定其他的主机组）。
如果在网络发现规则运行中在指定的IP范围中没有发现已经创建的主机时，这个由网络发现规则创建的主机会自动删除。
通过网络发现创建新的主机后，还需要在主机中创建相应的接口，创建接口时依照下列原则：
检测服务。例如，如果SNMP检测成功，将创建一个SNMP接口。
如果主机同时响应了Zabbixagent和SNMP的请求，两种接口都会创建。
如果以Zabbix agent 或SNMP返回的数据作为唯一条件，发现主机的第一个接口将会成为默认接口，其他的IP地址将添加为附加接口。
如果一个主机只响应agent checks，创建的接口只有agent 接口。如果以后响应SNMP，将添加额外的SNMP接口。
近日完成《深入浅出 zabbix 4.0》视频教程的录制并正式发布，该教程基于 zabbix 4.2 ，对Zabbix进行全面讲解。欢迎大家围观。课程链接：https://edu.51cto.com/sd/ce000
网络发现的配置分两部分，即配置rule（规则）和action（动作）。
在Configuration --> Discovery页面的右上角点击Create rule按钮创建网络发现规则，或者在页面列表中点击规则的名称修改配置。配置页面如下图12-1所示。
图 12-1
Rules配置页面中各参数的含义如下：
Name：唯一的规则名称。例如 Local network。
Discovery by proxy：选择no proxy是在Zabbix server上执行discovery，选择proxy server的名称是在相应的proxy server上执行。
IP range：发现的IP地址范围，支持多种格式：
单IP地址：192.168.10.10。
IP地址范围：192.168.1-10.1-255。包含的地址总数不能超过64000个。
IP 掩码：192.168.10.0/24。支持的IPv4掩码为 /16 - /30，IPv6的掩码为 /112 - /128。
IP地址列表：192.168.1.1-255, 192.168.2.1-100, 192.168.4.0/24
此外还支持spaces（空格）、tab，可以定义多行。
Delay (in sec)：自上一次执行规则之后再次执行规则的时间间隔，默认值为3600秒。
Checks：用于发现主机或服务的检测方法。支持的检测方法有：SSH、LDAP、SMTP、FTP、HTTP、HTTPS、POP、NNTP、IMAP、TCP、Telnet、Zabbix agent、SNMPv1 agent、SNMPv2 agent、SNMPv3 agent、ICMP ping。基于协议的发现只有net.tcp.service[]函数检测主机，SNMP通过查询SNMP OID检测主机，Zabbixagent在没有加密的传输模式下查询item检测主机。定义协议相关的Ports参数时，可以定义单端口（如22）、端口范围（如22-45）、端口列表（如22-45,55,60-70）。
Device uniqueness criteria：设备唯一性的标准。有两种：
IP address：不会对多个单IP地址的设备进行处理。如果相同IP地址的设备已经存在，将视为已经发现，不会创建新的主机。
Zabbix agent 或SNMP的检测方法：使用Checks自动中定义的agent或SNMP的方法。
Enabled：勾选为启用规则，Zabbix server将执行该规则。
配置好规则后，接下来继续配置动作。在Configuration --> Actions页面的右上角的Event source下拉框中选择Discovery，点击Create action按钮创建基于Discovery事件的动作，或者在页面列表中点击动作的名称修改配置。
配置动作最主要的就是配置Conditions（条件）和Operations（操作）。在Conditions中我们可以定义一系列的条件，如Discoverystatus、Service type、Host IP、Uptime/Downtime等，其中Received value条件是特别有用的，通过它可以区分不同的操作系统、应用程序的版本等。如下图12-2所示。
图 12-2
通过Conditions中配置的各种条件过滤出需要的主机之后，就需要采取一些操作，这些操作的配置在Operations标签中进行。如下图12-3所示。
图 12-3
从Operation type中我们可以看到可选的操作，通过这些操作可以自动的将符合发现规则的服务器或设备进行创建（或删除）主机、添加到主机组、链接模板等，从而实现自动化的监控。尤其是在经常有大量的新增设备或移除的环境中，更能体现出Zabbix 网络发现的优势。
在例子中假设网路的IP地址范围是192.168.1.1-192.168.1.254。需要实现的目标如下：
发现运行Zabbix agent的主机。
每10分钟运行一次discovery。
上线时间大于1小时的设备添加主机。
下线时间大于24小时的设备删除主机。
添加Linux主机到Linux servers主机组中。
链接Template OSLinux 到Linux 主机。
链接Template OSWindows到Windows主机。
第一步，定义网路发现规则。如下图12-4所示。
图 12-4
Zabbix将在IP地址范围192.168.1.1 – 192.168.1.1254中通过Zabbix agent尝试发现主机，并使用system.uname收集系统信息，在动作中可以利用收集的系统信息区分不同的操作系统，采取不同的操作，例如链接Template OS Windows模板到Windows服务器，链接Template OS Linux模板到Linux服务器。
这个规则创建后，Zabbix每10分钟执行一次（600秒），并生成基于发现规则的事件进行下一步处理。
第二步，定义一个动作将发现的Linux服务器添加指定的主机组和模板，如下图12-5所示。
图 12-5
从上图中我们可以看到，当Zabbix agent服务的状态是Up，system.uname的值中包含Linux，上线时间大于等于1小时（3600秒）的条件满足时，动作将被激活，执行相应的操作，如下图12-6所示。
图 12-6
从上图12-6中我们可以看到动作将执行下面的操作：
添加发现的主机到Linuxservers主机组中（如果主机还没有添加时也会添加主机）。
链接Template OSLinux 到发现的主机。Zabbix将使用模板中定义的监控项和触发器自动对主机进行监控。
第三步，定义一个动作将发现的Linux服务器添加指定的主机组和模板，如下图12-7所示。
图 12-7
第四步，定义一个删除主机的动作，如下图12-8所示。
图 12-8
如果发现的主机Zabbix agent 服务的状态是down，并超过24小时（86400秒）时服务器将被删除。
Active agent auto-registration（主动式代理自动注册）提供了另一种自动化的方法，不同与网络发现。网络发现时从server 端扫描网络，发现并完成一些自动化操作，而主动式代理自动注册是active agent 向Zabbix server发送查询监控项检测清单的请求时，主动将hostname、host metadata等信息提供给Zabbix server，由Zabbix server完成一些自动化操作。
使用主动式代理自动注册，可以自动添加active agent主机为监控主机并且不需要在Zabbixserver上做任何手工配置。同时也支持对监控主机使用Passivechecks进行监控，当active agent向Zabbix server发送查询监控项检测清单的请求时，也会把配置文件zabbix_agentd.conf中设置的 ListenIP（agent监听的IP地址）和ListenPort（agent监听的端口）提供给Zabbix server，在ListenIP中指定了多个IP地址时只有第一个IP地址会发送给Zabbix server。
当添加一个新的自动注册的主机时，会使用 agent配置文件中设置的IP地址和端口，如果在配置文件中没有设置IP地址，那在添加主机时会使用当前网路连接使用的IP地址。如果在配置文件中没有设置端口就使用默认的10050端口。
这种方式特别适合在云基础架构中实现新的云计算节点的自动化监控，当一个新节点开始运行时，Zabbix将自动监控节点，收集性能指标，监控节点的可用性。
首先需要在配置文件zabbix_agentd.conf中配置一些参数。
# vi /etc/zabbix/zabbix_agentd.conf
ServerActive=192.168.10.102
Hostname=test-server
其中ServerActive参数时必须配置的，格式为IP:port（或 hostname:port），可以指定单个或多个Zabbix server的IP地址和端口（用逗号分隔），如果没有指定端口则使用系统默认的端口。例如ServerActive=127.0.0.1:20051,zabbix.mydomain.com。也支持IPv6地址。
Hostname是唯一的大小写敏感的主机名称，在active（主动模式）中需要设置，自动注册主机时使用这个名称。如果没有设置这个参数，注册主机时会使用HostnameItem参数的值。配置文件中HostnameItem设置为system.hostname，即使用system.hostname这个Key收集主机名称，在Linux系统中实际上就是执行hostname命令收集主机名称。
当完成上述配置后，重启Zabbix agent服务。接下来创建一个基于auto-registration事件的动作。在Zabbix 前端页面中，点击Configuration--> Actions进入Actions列表页面，在页面右上角Event source下拉框中选择 Autoregistration，点击旁边的Create action按钮。在Action配置页面中的Conditions标签中添加条件Host name like test-server，如下图12-9所示。
图 12-9
在Operations标签中添加需要执行的操作，如下图12-10所示。
图 12-10
在链接模板时需要注意，如果自动注册的主机只支持active（主动式）监控方式，例如主机和Zabbixserver之间有防火墙，Zabbix server不能直接访问到自动注册的主机，在这种情况下需要指定一个监控项都使用Zabbix agent（active）监控方式的模板。例如Template_Linux-active。
如果自动注册的主机中监控项的监控方式使用Zabbix agent（被动式），需要在agent配置文件中下面的几个参数。
# vi /etc/zabbix/zabbix_agentd.conf
Server=192.168.10.102
ListenIP=
ListenPort-
其中Server参数需要设置为Zabbix server的IP地址或主机名，否则在agent的日志中出现failed to accept an incoming connection: connection from"192.168.10.102" rejected, allowed hosts: ""的信息，不能收集监控项的值。
ListenIP（agent监听的IP地址）和 ListenPort（agent监听的端口）可以设置也可以不设置，如果在配置文件中没有设置ListenIP，那在添加主机时会使用当前网路连接使用的IP地址。如果在配置文件中没有设置ListenPort就使用默认的10050端口。
动作配置完成后，稍等一会在主机列表中你就能看到自动注册的主机。在Monitoring --> Latest data页面中可以查询自动注册主机的监控项的值。
当active agent发送自动注册的请求到Zabbixserver的同时，会把agent配置文件中的Hostname也发送给Zabbixserver，但是在实际环境中，仅仅通过Hostname是不够的，在Hostname无法区分主机的情况下，以Hostname作为条件会出现很多问题。因此Zabbix中引入新的方法Host metadata来解决这个问题。
在zabbix_agentd.conf配置文件中，有两种方法可以配置Hostmetadata。Host metadata仅在active agent自动注册过程中使用
HostMetadata，可设置长度不超过255个字符的字符串。如果没有设置该参数，将从HostMetadataItem参数收集。如果设置的值长度超过255或字符串中使用了非UTF-8的字符串时，agent会启动失败并在日志中生成错误信息。
HostMetadataItem，该参数仅在没有设置HostMetadata参数时使用。支持UserParameters和aliases，支持system.run[]（无论EnableRemoteCommands参数是否设置）。如果指定的监控项返回值超过255个字符时会在日志中生成错误信息。另外监控项的返回值必须是一个UTF-8字符串，否则它将被忽略。
实例一：使用host metadata区分Linux和Windows主机。
1、 在agent配置文件中设置：HostMetadataItem=system.uname。重启Zabbix agent服务。
2、 在Zabbix前端页面配置2个动作。
动作 1：
Name：Linux host autoregistration
Conditions：Host metadata like Linux
Operations：Link to Templates: Template os Linux
动作 2：
Name：Windows host autoregistration
Conditions：Host metadata like Windows
Operations：Link to templates: Template OS Windows
你可能注意到在Operations中只加入了一个链接到模板操作，没有添加主机的操做。实际上这是没有问题的，因为链接到模板的操作首先需要添加一个主机，在这里Zabbix server会自动添加主机。
实例二：使用host metadata添加特定的主机。
1、 在agent配置文件中设置：HostMetadata=Linux onlydemo。重启Zabbix agent服务。
2、 在Zabbix前端页面配置动作。
Name：Linux host autoregistration
Type of calculation：AND
Conditions (A)：Host metadata like Linux
Conditions (B)：Host metadata like onlydemo
Operations：Link to Templates: Template os Linux
Add to host groups: Linux servers
12.3 Low-level discovery
Low-level discovery是Zabbix中提供的一种非常有用的功能，通过在模板中配置low-level discovery，可以自动创建监控项、触发器、图形和主机。尤其是在监控对象动态变换的环境中，可以定期的执行发现规则，自动添加或删除监控对象，例如网络接口的数量和类型、文件系统的类型等，如果为主机的每个网络接口和每一种文件系统手工创建监控项和触发器，可以想见工作量是巨大的，而通过Low-level discovery可以代替手工方式自动化的完成相关任务。
发现规则由监控项和基于监控项的返回值创建的原型（items、triggers、graphs和host）两部分组成。发现规则中的监控项和在主机中定义的监控项非常相似，不同的是发现规则中监控项返回值是一个特定的JSON格式的监控对象（如网路接口）的列表，例如net.if.discovery的返回值可能是：{#IFNAME} → lo 和 {#IFNAME} → eth0。
当Zabbix server接收到发现规则中监控项的返回值后，会根据返回值中的macro --> value在原型中创建items、triggers、graphs或hosts。这些宏变量可以在name、keys或其他原型中的字段中使用，这些位置包括：
在item prototypes中
names
key parameters
units
SNMP OIDs
IPMI sensor fields
calculated item formulas
SSH and Telnet scripts
database monitor itemparameters
descriptions
在triggerprototypes 中
names
expressions
URLs
descriptions
在graphprototypes 中
names
在host prototypes中
names
visible names
host group prototype names
在Zabbix中支持下列六种发现规则：
discovery of file systems
discovery of network interfaces
discovery of CPUs and CPU cores
discovery of SNMP OIDs
discovery using ODBC SQLqueries
discovery of Windows services
另外我们也可以自定义发现规则，只需要数据格式遵循特定的JSON协议即可，详细内容如下表12-1所示。
表 12-1
item的key | Item类型 | 返回值 |
vfs.fs.discovery | Zabbix agen | { "data": [ {"{#FSNAME}": {"{#FSNAME}": {"{#FSNAME}": …] } |
net.if.discovery | Zabbix agent | { "data":[ {"{#IFNAME}":" {"{#IFNAME}":" {"{#IFNAME}":" } |
system.cpu.discovery | Zabbix agent | { "data":[ {"{#CPU.NUMBER}":" {"{#CPU.NUMBER}":" {"{#CPU.NUMBER}":" …] } |
db.odbc.discovery | Database monitor | { "data": [ {"{#HOST}": " {"{#HOST}": " {"{#HOST}": " …] } |
snmp.discovery | SNMP (v1, v2, or v3) agent | { "data":[ } |
Service.discovery | Zabbix agent | { "data":[ {"{#SERVICE.DISPLAYNAME}": " "{#SERVICE.NAME}": " "{#SERVICE.PATH}": " "{#SERVICE.STARTUPNAME}": " "{#SERVICE.STARTUP}": “ "{#SERVICE.STATENAME}": " "{#SERVICE.STATE}":” "{#SERVICE.TYPENAME}": " "{#SERVICE.TYPE}": “ "{#SERVICE.USER}": " ...] } |
custom.discovery | Any | { "data":[ {"{#CUSTOM1}":" {"{#CUSTOM1}":" {"{#CUSTOM1}":" …] } |
当我们准备开始定义发现规则时，可以通过zabbix_get工具查看Key收集的数据。例如：
# zabbix_get -s 127.0.0.1 -k net.if.discovery
{"data":[
{"{#IFNAME}":"enp0s3"},
{"{#IFNAME}":"lo"}
]}
# zabbix_get -s 127.0.0.1 -k vfs.fs.discovery
{"data":[
{"{#FSNAME}":"/","{#FSTYPE}":"rootfs"},
{"{#FSNAME}":"/sys","{#FSTYPE}":"sysfs"},
{"{#FSNAME}":"/proc","{#FSTYPE}":"proc"},
{"{#FSNAME}":"/dev","{#FSTYPE}":"devtmpfs"},
{"{#FSNAME}":"/sys/kernel/security","{#FSTYPE}":"securityfs"},
{"{#FSNAME}":"/dev/shm","{#FSTYPE}":"tmpfs"},
{"{#FSNAME}":"/dev/pts","{#FSTYPE}":"devpts"},
{"{#FSNAME}":"/run","{#FSTYPE}":"tmpfs"},
…
]}
SNMP发现规则的Key不能通过zabbix_get工具验证，只能在Web页面中进行配置使用。
在Configuration --> Templates页面中，点击模板的Discovery列中的链接，如下图12-11所示。
图 12-11
创建Low-level discovery规则
在Discovery rules页面中点击右上角的Creatediscovery rule按钮可以创建新的发现规则。如下图12-12所示。
图 12-12
Discovery rule标签中各参数的含义如下：
Name：发现规则的名称。
Type：用于发现的监控方式。
Key：item的key，如vfs.fs.discovery。
Update interval (in sec)：执行发现规则的间隔时间，单位是秒。如果设置为0，item将停止收集数据。
Custom intervals：设置Flexible或Scheduling。
Keep lost resources period (indays)：当发现状态变为Not discoveredanymore时，保留发现记录的天数。最大为3650天。如果设置为0将立即删除，不会保留。
Description：描述信息。
Enabled：勾选此项为启用该发现规则。
Filters标签中设置filters计算类型，通过点击Add连接添加多个宏变量。如下图12-13所示。
图 12-13
其中各参数的含义如下：
Type of calculation：计算Filters的类型。有以下几种类型：
And：必须满足所有filters。
Or：只有满足其中一个filters。
And/Or：不同的宏变量使用And，相同的宏变量使用Or。
Custom expression：自定义filters计算，公式中必须包括列表中所有filters，不能超过255个字符。
Filters：使用宏变量匹配正在表达式。在Regular expression中正则表达式可以直接输入，也可以引用 Administration --> General --> Regular expressions中定义的全局正则表达式。例如只需要监测文件系统类型为ext和reiserfs的文件系统，使用{#FSTYPE}匹配正则表达式^ext|^reiserfs，此时监控项返回值中只包括文件系统类型为 ext或reiserfs的数据。
所有的参数设置后，点击Add按钮保存。
创建文件系统的发现规则时，使用Zabbix agent监控方式，Key使用vfs.fs.discovery，在Filters中需要使用{#FSTYPE}匹配正在表达式，得到你想要的数据，windows agent还支持{#FSDRIVETYPE}，例如{#FSDRIVETYPE} --> “fixed”。正则表达式可以使用命令grep –E进行检测。例如：for f inext2 nfs reiserfs smbfs; do echo $f | grep -E '^ext|^reiserfs' || echo"SKIP: $f"; done。
创建网络接口的发现规则时，使用Zabbix agent监控方式，Key使用net.if.discovery，在Filters中使用{#IFNAME}匹配正则表达式。在此规则上你可以创建 item prototypes，例如 net.if.in[{#IFNAME},bytes]”,“net.if.out[{#IFNAME},bytes]。
创建CPUs和CPU cores发现规则时，使用Zabbix agent监控方式，Key使用system.cpu.discovery，这个Key返回两个macros，即 {#CPU.NUMBER} 和{#CPU.STATUS}，需要注意的是这里不能明确的区分出实际的物理处理器、内核和超线程。{#CPU.STATUS} 在Linux、UNIX 和 BSD系统中返回处理器的状态为 online 或 offline，在Windows系统中可能是unknown，意思是已经检测到处理器，但还没有收集到更多的信息。在此规则上你可以创建 item prototypes，例如system.cpu.util[{#CPU.NUMBER},
创建SNMP OIDs 的发现规则时，不像定义文件系统或网络接口的发现规则，不使用snmp.discovery这个Key，使用SNMP agnet监控方式就可以，在SNMPOID字段中定义需要发现的OIDs，格式为 discovery[{#MACRO1}, oid1, {#MACRO2}, oid2, …,]。如下图12-14所示。
图 12-14
创建ODBC SQL查询的发现规则时，需要使用SQL查询并将结果自动转换成JSON格式。Key使用db.odbc.select[
图 12-15
创建Windows服务的发现规则时，使用Zabbixagent监控方式，Key使用service.discovery，和创建文件系统的发现规则方法一样，在Filters中支持使用下面的这些macros：{#SERVICE.NAME}、{#SERVICE.DISPLAYNAME}、{#SERVICE.DESCRIPTION}、{#SERVICE.STATE}、{#SERVICE.STATENAME}、{#SERVICE.PATH}、{#SERVICE.USER}、{#SERVICE.STARTUP}、{#SERVICE.STARTUPNAME}。在此规则上你可以创建item prototypes，例如 service.info[{#SERVICE.NAME},]，param可以是state、displayname、path、user、startup和description，如果param没有指定，默认返回state。{#SERVICE.STATE}和 {#SERVICE.STATENAME}返回相同的内容，{#SERVICE.STATE} 返回的是数值（0 - 7），{#SERVICE.STATENAME}返回的是文字（running,paused、start pending、pause pending、continuepending、stop pending、stopped or unknown）。{#SERVICE.STARTUP}返回的是数值（0 -4），{#SERVICE.STARTUPNAME}返回的是文字（automatic、automatic delayed、 manual、disabled、unknown）。
创建自定义的发现规则时，可以使用任意的监控方式。通常使用脚本生成JOSN格式的数据，在自定义发现规则中，宏变量的数量没有限制，
1、Item原型
当发现规则创建成功后，在发现规则列表中点击ITEMS列中的item prototypes链接，在item prototypes页面中点击右上角的Createitem prototype按钮进入Item prototype配置页面。如下图12-16所示。
图 12-16
在Name和Key中需要使用macro，如上图中的{#FSNAME}。Application prototypes是一个比较特殊的选项，在这个选项中也可以使用宏变量。在同一个发现规则中几个item prototypes可以使用同一个applicationprototypes。
2、Trigger原型
在发现规则列表中点击TRIGGERS列中的 Trigger prototypes链接，在Trigger prototypes页面中点击右上角的Createtrigger prototype按钮进入Trigger prototype配置页面。如下12-17图所示。
图 12-17
在Dependencies标签中可以定义依赖的triggerprototypes。一个触发器原型可以依赖于相同发现规则下的另一个触发器原型或一个常规的触发器。一个触发器原型不能依赖于其他发现规则下的触发器原型或从一个触发器原型创建的触发器。
3、Graph原型
在发现规则列表中点击GRAPHS列中的Graph prototypes链接，在Graph prototypes页面中点击右上角的CreateGraph prototype按钮进入Graph prototype配置页面。如下图12-18所示。
图 12-18
4、Host原型
在发现规则列表中点击HOSTS列中的Host prototypes链接，在Host prototypes页面中点击右上角的CreateHost prototype按钮进入Host prototype配置页面。如下图12-19所示。
图 12-19
在Host 原型中，可以链接模板，在host name、visible name和groupprototypes中使用LLD 宏变量。通过Host原型创建的主机是以发现规则的名称为名称前缀创建的，在Web前端主机列表中，这些主机可以手工删除，也可以自动删除（基于发现规则中定义的Keep lost resources period (in days)参数设置）。除了Enable选项和host inventory外，大部分选项都是只读的。
在Zabbix中提供的模板 Template VirtVMware中，在 Discover VMware VMs 和Discover VMware hypervisors 发现规则中定义了Host prototypes，分别用来发现和创建虚拟机和VMwareESX服务器的监控主机，可以作为参考更好的理解Host prototypes。
本文出自 http://ustogether.blog.51cto.com/8236854/1929748，如需转载请与作者联系。