Shulou(Shulou.com)06/02 Report--

Chapter XII Zabbix Automation

Through the study of the previous chapter, you will find that Zabbix is a very flexible and powerful monitoring system, but configuring Zabbix in the real environment is a very heavy task. Fortunately, Zabbix provides some tools that allow Zabbix to automate tasks and make operation and maintenance work easier.

The main automation tools of Zabbix are networkdiscovery (Network Discovery), active agentauto-registration (automatic Registration of active agents) and Low-leveldiscovery (low-level Discovery).

12.1 Network Discovery

Network discovery in Zabbix consists of two parts: discovery (Discovery) and actions (Action). Firstly, it scans the network periodically and searches for servers or devices in the network according to predefined rules. Generate discovery events when finding qualified servers or devices, and then combine our defined actions based on discovery events to discover and add / delete hosts and other simple management, and quickly build a monitoring system according to the network environment. These actions include:

Create or delete hosts.

Enable or disable the host.

Add hosts to the host group.

Remove from the host group.

Link the template to the host or unlink the template.

Send a notification.

Execute remote commands.

Within the specified range of IP addresses, Zabbix uses the following three methods to detect servers or devices in the network:

Information received from Zabbix agent (encryption mode is not supported).

Information received from SNMP agent.

Availability based on services (FTP, SSH, WEB, POP3, IMAP, TCP, etc.).

12.1.1 Discovery event

Network discovery generates a discovery event each time the detection of a host (IP) and service is completed. The list of events that can be generated is as follows:

Service Discovered: the status of the first discovery or service used to be down, but now it is up.

Service Up: the status of the service has always been up.

Service Lost: the status of the service used to be up, but now it is down.

Service Down: the status of the service has always been down.

Host Discovered: all services on the host used to have a status of down, but now at least one service has a status of up.

Host Up: the status of at least one service on the host has always been up.

Host Lost: the host used to have at least one service with a status of up, but now all services have a status of down.

Host Down: the status of all services on the host has always been down.

Creation and deletion of hosts

If the Add host action is selected in the action, the newly discovered host is automatically created, and the following actions can be defined in the action:

Allow hosts

Disable host

Add a host to the host group

Link template to host

When you create a host, the host name is named after the result of the DNS reverse query by Zabbix server or proxy server, or by the IP address if the reverse query fails. Whether or not to retry after a failed reverse query depends on where the discovery executes, and does not retry after a failed query on proxyserver.

When the newly created host name already exists in Zabbix server, the name of the newly created host is appended to the name _ 2 for the second host with the same name, _ 3 for the third host with the same name, and so on.

The newly created host is added to the Discovered hosts group host group by default, which is configured in the Group fordiscovered hosts parameter on the Administration-- > General-- > Other page. If you want the host to be added to other host groups, you need to add Remove from host groups (specify Discovered hosts) and Add tohost groups (specify other host groups) in the action.

If a host that has been created is not found in the specified IP range while the network discovery rule is running, the host created by the network discovery rule is automatically deleted.

12.1.3 creation of host interface

After creating a new host through network discovery, you also need to create the appropriate interface in the host according to the following principles:

Testing service. For example, if SNMP detection is successful, a SNMP interface will be created.

If the host responds to both Zabbixagent and SNMP requests, both interfaces are created.

If the only condition is the data returned by Zabbix agent or SNMP, the first interface of the discovered host will become the default interface, and the other IP addresses will be added as additional interfaces.

If a host responds only to agent checks, only the agent interface is created. If you respond to SNMP later, additional SNMP interfaces will be added.

Recently, we have completed the recording and release of the video tutorial "zabbix 4.0", which is based on zabbix 4.2 and provides a comprehensive explanation of Zabbix. Welcome to watch. Course link: https://edu.51cto.com/sd/ce000

12.1.4 configure rules and actions

The configuration of network discovery is divided into two parts, namely, configuring rule (rules) and action (actions).

Click the Create rule button in the upper right corner of the Configuration-> Discovery page to create a network discovery rule, or click the name of the rule in the list of pages to modify the configuration. The configuration page is shown in figure 12-1 below.

Figure 12-1

The parameters in the Rules configuration page are as follows:

Name: the unique rule name. For example, Local network.

Discovery by proxy: select no proxy to execute discovery on Zabbix server, and select the name of proxy server to execute on the corresponding proxy server.

IP range: discovered IP address range, which supports multiple formats:

Single IP address: 192.168.10.10.

The IP address range is 192.168.1-10.1255. The total number of addresses contained cannot exceed 64000.

IP mask: 192.168.10.0. The supported IPv4 mask is / 16-/ 30 and the mask for IPv6 is / 112-/ 128.

IP address list: 192.168.1.1-255,192.168.2.1-100,192.168.4.0

In addition, it also supports spaces (spaces), tab, and can define multiple lines.

Delay (in sec): the interval between the execution of a rule since the last time the rule was executed. The default value is 3600 seconds.

Checks: the detection method used to discover hosts or services. The supported detection methods are: SSH, LDAP, SMTP, FTP, HTTP, HTTPS, POP, NNTP, IMAP, TCP, Telnet, Zabbix agent, SNMPv1 agent, SNMPv2 agent, SNMPv3 agent, ICMP ping. In the discovery based on the protocol, only the net.tcp.service [] function detects the host, SNMP detects the host by querying SNMP OID, and Zabbixagent queries the item detection host in unencrypted transmission mode. When defining protocol-related Ports parameters, you can define a single port (such as 22), a port range (such as 22-45), and a port list (such as 22-45, 55, 60-70).

Device uniqueness criteria: the standard for device uniqueness. There are two kinds:

IP address: devices with multiple single IP addresses are not processed. If a device with the same IP address already exists, it will be considered discovered and no new host will be created.

Detection method of Zabbix agent or SNMP: use the method of agent or SNMP defined in Checks automatically.

Enabled: check to enable the rule and Zabbix server will execute the rule.

Once the rules are configured, proceed with the configuration actions. Select Discovery in the Event source drop-down box in the upper right corner of the Configuration-> Actions page, click the Create action button to create an action based on the Discovery event, or click the name of the action in the page list to modify the configuration.

The most important part of the configuration action is to configure Conditions (condition) and Operations (action). In Conditions, we can define a series of conditions, such as Discoverystatus, Service type, Host IP, Uptime/Downtime, etc., among which the Received value condition is particularly useful, through which we can distinguish different operating systems, versions of applications, and so on. This is shown in figure 12-2 below.

Figure 12-2

After filtering out the required hosts through the various conditions configured in Conditions, you need to take some actions, which are configured in the Operations tag. This is shown in figure 12-3 below.

Figure 12-3

From the Operation type, we can see the optional operations, through which the servers or devices that meet the discovery rules can be automatically created (or deleted) hosts, added to host groups, link templates, etc., so as to achieve automatic monitoring. Especially in the environment where there are often a large number of new devices or removals, it can better reflect the advantages of Zabbix network discovery.

12.1.5 configure an instance

In the example, it is assumed that the IP address range of the network is 192.168.1.1-192.168.1.254. The goals to be achieved are as follows:

Found the host running Zabbix agent.

Run discovery every 10 minutes.

Add hosts to devices that have been online for more than 1 hour.

Delete the host for devices that have been offline for more than 24 hours.

Add Linux hosts to the Linux servers host group.

Link Template OSLinux to the Linux host.

Link Template OSWindows to the Windows host.

The first step is to define network discovery rules. This is shown in figure 12-4 below.

Figure 12-4

Zabbix will try to discover the host through Zabbix agent in the IP address range 192.168.1.1-192.168.1.1254, and use system.uname to collect system information. In the action, you can use the collected system information to distinguish different operating systems and take different actions, such as linking the Template OS Windows template to the Windows server and the Template OS Linux template to the Linux server.

After this rule is created, Zabbix executes it every 10 minutes (600 seconds) and generates events based on the discovery rule for further processing.

The second step is to define an action to add the specified host group and template to the discovered Linux server, as shown in figure 12-5 below.

Figure 12-5

As we can see from the figure above, when the status of the Zabbix agent service is Up,system.uname, the value contains Linux, and the condition that the live time is greater than or equal to 1 hour (3600 seconds) is met, the action will be activated and the corresponding action will be performed, as shown in figure 12-6 below.

Figure 12-6

From figure 12-6 above, we can see that the action will perform the following actions:

Add discovered hosts to the Linuxservers host group (and add hosts if they have not already been added).

Link the Template OSLinux to the discovered host. Zabbix will automatically monitor the host using the monitoring items and triggers defined in the template.

The third step is to define an action to add the specified host group and template to the discovered Linux server, as shown in figure 12-7 below.

Figure 12-7

Step 4, define an action to delete the host, as shown in figure 12-8 below.

Figure 12-8

If the status of the discovered host Zabbix agent service is down, and the server is deleted for more than 24 hours (86400 seconds).

12.2 Active agent auto-registration

Active agent auto-registration (active Agent Auto Registration) provides another automated method, which is different from network discovery. When the network is discovered, the network is scanned from the server side, and some automatic operations are found and completed. The active agent automatic registration is that when active agent sends a request to Zabbix server to query the inspection list of monitoring items, it actively provides hostname, host metadata and other information to Zabbix server, and Zabbix server completes some automatic operations.

Using active agent auto-registration, the active agent host can be automatically added as the monitoring host without any manual configuration on the Zabbixserver. At the same time, it also supports the use of Passivechecks to monitor the monitoring host. When active agent sends a request to Zabbix server to query the detection list of monitoring items, it will also provide ListenIP (IP address for agent listening) and ListenPort (port for agent listening) set in the configuration file zabbix_agentd.conf to Zabbix server. When multiple IP addresses are specified in ListenIP, only the first IP address will be sent to Zabbix server.

When adding a new auto-registered host, the IP address and port set in the agent configuration file are used, and if the IP address is not set in the configuration file, the IP address used by the current network connection is used when adding the host. If the port is not set in the configuration file, the default port 10050 is used.

This approach is especially suitable for automatic monitoring of new cloud computing nodes in the cloud infrastructure. When a new node starts running, Zabbix will automatically monitor the node, collect performance indicators, and monitor the availability of the node.

12.2.1 configure and create host

First, you need to configure some parameters in the configuration file zabbix_agentd.conf.

# vi / etc/zabbix/zabbix_agentd.conf

ServerActive=192.168.10.102

Hostname=test-server

If the ServerActive parameter must be configured, the format is IP:port (or hostname:port). You can specify the IP address and port of one or more Zabbix server (separated by commas). If no port is specified, the default port of the system is used. For example, ServerActive=127.0.0.1:20051,zabbix.mydomain.com. IPv6 addresses are also supported.

Hostname is the only case-sensitive host name that needs to be set in active (active mode) and is used when registering hosts automatically. If this parameter is not set, the value of the HostnameItem parameter is used when registering the host. HostnameItem is set to system.hostname in the configuration file, and even if you use the Key of system.hostname to collect host names, on the Linux system, you actually execute the hostname command to collect host names.

When the above configuration is completed, restart the Zabbix agent service. Next, create an action based on the auto-registration event. In the Zabbix front-end page, click Configuration-- > Actions to enter the Actions list page, select Autoregistration in the Event source drop-down box in the upper right corner of the page, and click the Create action button next to it. Add the conditional Host name like test-server to the Conditions tag on the Action configuration page, as shown in figure 12-9 below.

Figure 12-9

Add the actions you need to perform in the Operations tag, as shown in figure 12-10 below.

Figure 12-10

Note that if the auto-registered host only supports active (active) monitoring mode, for example, there is a firewall between the host and Zabbixserver, and Zabbixserver cannot directly access the auto-registered host, in this case, you need to specify a template in which all monitoring items use Zabbix agent (active) monitoring method. For example, Template_Linux-active.

If the monitoring items in the auto-registered host are monitored using Zabbix agent (passive), the following parameters are required in the agent configuration file.

# vi / etc/zabbix/zabbix_agentd.conf

Server=192.168.10.102

ListenIP=

ListenPort-

The Server parameter needs to be set to the IP address or hostname of Zabbix server, otherwise the information of failed to accept an incoming connection: connection from "192.168.10.102" rejected, allowed hosts: "will appear in the log of agent, and the value of monitoring items cannot be collected.

ListenIP (IP address for agent listening) and ListenPort (port for agent listening) can be set or not set. If ListenIP is not set in the configuration file, the IP address used by the current network connection will be used when adding hosts. If ListenPort is not set in the configuration file, the default port 10050 is used.

After the action configuration is complete, you can see the automatically registered hosts in the list of hosts in a moment. You can query the value of the monitor entry of the auto-registered host in the Monitoring-- > Latest data page.

12.2.2 configuring Host metadata

When active agent sends a request for automatic registration to Zabbixserver, it will also send the Hostname in the agent configuration file to Zabbixserver, but in the actual environment, only through Hostname is not enough, in the case that Hostname can not distinguish between hosts, there will be a lot of problems with Hostname as a condition. Therefore, a new method Host metadata is introduced into Zabbix to solve this problem.

In the zabbix_agentd.conf configuration file, there are two ways to configure Hostmetadata. Host metadata is only used during active agent automatic registration

HostMetadata, which allows you to set a string that is no more than 255characters long. If this parameter is not set, it will be collected from the HostMetadataItem parameter. If you set a value longer than 255or a string other than UTF-8 is used in the string, agent fails to start and generates an error message in the log.

HostMetadataItem, which is used only when the HostMetadata parameter is not set. Supports UserParameters and aliases, and supports system.run [] (regardless of whether the EnableRemoteCommands parameter is set or not). If the return value of the specified monitoring item exceeds 255 characters, an error message is generated in the log. In addition, the return value of the monitoring item must be a UTF-8 string, otherwise it will be ignored.

12.2.2 using Host metadata instances

Example 1: use host metadata to distinguish between Linux and Windows hosts.

1. Set: HostMetadataItem=system.uname in the agent configuration file. Restart the Zabbix agent service.

2. Configure 2 actions on the front-end page of Zabbix.

Action 1:

Name:Linux host autoregistration

Conditions:Host metadata like Linux

Operations:Link to Templates: Template os Linux

Action 2:

Name:Windows host autoregistration

Conditions:Host metadata like Windows

Operations:Link to templates: Template OS Windows

You may have noticed that only a link to the template action has been added to the Operations, not the host operation. In fact, this is no problem, because the operation of linking to the template first needs to add a host, where Zabbix server will automatically add the host.

Example 2: use host metadata to add specific hosts.

1. Set: HostMetadata=Linux onlydemo in the agent configuration file. Restart the Zabbix agent service.

2. Configure actions on the front-end page of 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 is a very useful feature provided in Zabbix. By configuring low-level discovery in a template, you can automatically create monitoring items, triggers, graphics, and hosts. Especially in an environment where monitoring objects are dynamically transformed, discovery rules can be executed periodically to automatically add or delete monitoring objects, such as the number and type of network interfaces, the type of file system, and so on. If you manually create monitoring items and triggers for each network interface of the host and each file system, you can imagine that the workload is huge. The related tasks can be completed automatically by Low-level discovery instead of manual way.

The discovery rule consists of monitoring items and prototypes (items, triggers, graphs, and host) created based on the return values of monitoring items. The monitoring items in the discovery rule are very similar to those defined in the host, except that the return value of the monitoring item in the discovery rule is a list of monitoring objects (such as network interfaces) in a specific JSON format. For example, the return values of net.if.discovery may be: {# IFNAME} → lo and {# IFNAME} → eth0.

When Zabbix server receives the return value of the monitoring item in the discovery rule, it creates an items, triggers, graphs, or hosts in the prototype based on the macro-> value in the return value. These macro variables can be used in fields in name, keys, or other prototypes, and these locations include:

In item prototypes

Names

Key parameters

Units

SNMP OIDs

IPMI sensor fields

Calculated item formulas

SSH and Telnet scripts

Database monitor itemparameters

Descriptions

In triggerprototypes

Names

Expressions

URLs

Descriptions

In graphprototypes

Names

In host prototypes

Names

Visible names

Host group prototype names

The following six discovery rules are supported in 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

In addition, we can also customize the discovery rules, as long as the data format follows a specific JSON protocol, as shown in Table 12-1.

Table 12-1

Key of item

Item Typ

Return value

Vfs.fs.discovery

Zabbix agen

{

"data": [

{"{# FSNAME}": "," {# FSTYPE} ":"}

{"{# FSNAME}": "," {# FSTYPE} ":"}

{"{# FSNAME}": "," {# FSTYPE} ":"}

[]

}

Net.if.discovery

Zabbix agent

{

"data": [

{"{# IFNAME}": ""}

{"{# IFNAME}": ""}

{"{# IFNAME}": ""}

[]

}

System.cpu.discovery

Zabbix agent

{

"data": [

{"{# CPU.NUMBER}": "", "{# CPU.STATUS}": ""}

{"{# CPU.NUMBER}": "", "{# CPU.STATUS}": ""}

{"{# CPU.NUMBER}": "", "{# CPU.STATUS}": ""}

[]

}

Db.odbc.discovery

Database monitor

{

"data": [

{"{# HOST}": "", "{# COUNT}": ""}

{"{# HOST}": "", "{# COUNT}": ""}

{"{# HOST}": "", "{# COUNT}": ""}

[]

}

Snmp.discovery

SNMP (v1, v2, or v3) agent

{

"data": [

{"{# SNMPINDEX}": "", "{# SNMPVALUE}": ""}

{"{# SNMPINDEX}": "", "{# SNMPVALUE}": ""}

{"{# SNMPINDEX}": "", "{# SNMPVALUE}": ""}

[]

}

Service.discovery

Zabbix agent

{

"data": [

{"{# SERVICE.DISPLAYNAME}": ""

"{# SERVICE.NAME}": ""

"{# SERVICE.PATH}": ""

"{# SERVICE.STARTUPNAME}": ""

"{# SERVICE.STARTUP}": ""

"{# SERVICE.STATENAME}": ""

"{# SERVICE.STATE}": ""

"{# SERVICE.TYPENAME}": "r"

"{# SERVICE.TYPE}": ""

"{# SERVICE.USER}": ""}

...]

}

Custom.discovery

Any

{

"data": [

{"{# CUSTOM1}": "", "{# CUSTOM2}": ""}

{"{# CUSTOM1}": "", "{# CUSTOM2}": ""}

{"{# CUSTOM1}": "", "{# CUSTOM2}": ""}

[]

}

When we are ready to start defining discovery rules, we can view the data collected by Key through the zabbix_get tool. For example:

# 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"}

...

]}

The Key of the SNMP discovery rule cannot be verified by the zabbix_get tool and can only be configured and used in the Web page.

12.3.1 create Discovery rules

On the Configuration-- > Templates page, click the link in the Discovery column of the template, as shown in figure 12-11 below.

Figure 12-11

Create a Low-level discovery rule

Click the Creatediscovery rule button in the upper right corner of the Discovery rules page to create a new discovery rule. This is shown in figure 12-12 below.

Figure 12-12

The parameters in the Discovery rule tag have the following meanings:

Name: the name of the discovery rule.

Type: monitoring method for discovery.

Key of Key:item, such as vfs.fs.discovery.

Update interval (in sec): the interval between the execution of discovery rules, in seconds. If set to 0 _ item, data collection will stop.

Custom intervals: sets Flexible or Scheduling.

Keep lost resources period (indays): the number of days to keep the discovery record when the discovery state changes to Not discoveredanymore. The maximum is 3650 days. If set to 0, it will be deleted immediately and will not be retained.

Description: description information.

Enabled: check this to enable the discovery rule.

Set the filters calculation type in the Filters tab and add multiple macro variables by clicking on the Add connection. This is shown in figure 12-13 below.

Figure 12-13

The meanings of the parameters are as follows:

Type of calculation: calculates the type of Filters. There are several types:

And: all filters must be met.

Or: only one of the filters is satisfied.

And/Or: different macro variables use And, and the same macro variables use Or.

Custom expression: custom filters calculation. All filters in the list must be included in the formula, which cannot exceed 255characters.

Filters: use macro variables to match the expression. In Regular expression, regular expressions can be entered directly or refer to global regular expressions defined in Administration-- > General-- > Regular expressions. For example, you only need to monitor file systems with file system types of ext and reiserfs, and use {# FSTYPE} to match the regular expression ^ ext | ^ reiserfs. In this case, the returned value of the monitoring item includes only data of file system type ext or reiserfs.

After all the parameters have been set, click the Add button to save.

When creating file system discovery rules, use Zabbix agent monitoring method, Key uses vfs.fs.discovery, in Filters, you need to use {# FSTYPE} to match the expression to get the data you want. Windows agent also supports {# FSDRIVETYPE}, such as {# FSDRIVETYPE}-> "fixed". Regular expressions can be detected using the command grep-E. For example: for f inext2 nfs reiserfs smbfs; do echo $f | grep-E'^ ext | ^ reiserfs' | | echo "SKIP: $f"; done.

When creating discovery rules for network interfaces, Zabbix agent monitoring is used, Key uses net.if.discovery, and {# IFNAME} is used in Filters to match regular expressions. You can create item prototypes on this rule, such as net.if.in [{# IFNAME}, bytes] "," net.if.out [{# IFNAME}, bytes].

When creating CPUs and CPU cores discovery rules, use Zabbix agent monitoring method, and Key uses system.cpu.discovery. This Key returns two macros, namely {# CPU.NUMBER} and {# CPU.STATUS}. It should be noted that the actual physical processor, kernel and hyper-thread cannot be clearly distinguished here. {# CPU.STATUS} returns the status of the processor as online or offline in Linux, UNIX, and BSD systems, or unknown in Windows systems, meaning that the processor has been detected, but no more information has been collected. You can create an item prototypes on this rule, such as system.cpu.util [{# CPU.NUMBER},] "or" system.hw.cpu [{# CPU.NUMBER},].

When creating discovery rules for SNMP OIDs, unlike those that define file systems or network interfaces, you can use SNMP agnet monitoring instead of snmp.discovery Key. Define the OIDs to be discovered in the SNMPOID field in the format of discovery [{# MACRO1}, oid1, {# MACRO2}, oid2, … ,] . This is shown in figure 12-14 below.

Figure 12-14

When creating discovery rules for ODBC SQL queries, you need to use SQL queries and automatically convert the results to JSON format. Key uses db.odbc.select [,], and the monitoring method is Database monitor. As shown in figure 12-15 below.

Figure 12-15

When creating discovery rules for Windows services, Zabbixagent monitoring method is used. Key uses service.discovery, which is the same as the method of creating file system discovery rules. The following macros are supported in Filters: {# SERVICE.NAME}, {# SERVICE.DISPLAYNAME}, {# SERVICE.DESCRIPTION}, {# SERVICE.STATE}, {# SERVICE.STATENAME}, {# SERVICE.PATH}, {# SERVICE.USER}, {# SERVICE.STARTUP}, {# SERVICE.STARTUPNAME}. You can create item prototypes on this rule, such as service.info [{# SERVICE.NAME},]. Param can be state, displayname, path, user, startup and description. If param is not specified, state is returned by default. {# SERVICE.STATE} and {# SERVICE.STATENAME} return the same content, {# SERVICE.STATE} returns numeric values (0-7), and {# SERVICE.STATENAME} returns text (running,paused, start pending, pause pending, continuepending, stop pending, stopped or unknown). {# SERVICE.STARTUP} returns numeric values (0-4) and {# SERVICE.STARTUPNAME} returns text (automatic, automatic delayed, manual, disabled, unknown).

When creating custom discovery rules, you can use any monitoring method. Scripts are usually used to generate data in JOSN format. In custom discovery rules, there is no limit to the number of macro variables.

12.3.2 create a prototype

1. Item prototype

When the discovery rule is created successfully, click the item prototypes link in the ITEMS column in the list of discovery rules, and click the Createitem prototype button in the upper right corner of the item prototypes page to enter the Item prototype configuration page. This is shown in figure 12-16 below.

Figure 12-16

You need to use macro in Name and Key, such as {# FSNAME} in the figure above. Application prototypes is a special option in which macro variables can also be used. Several item prototypes in the same discovery rule can use the same applicationprototypes.

2. Trigger prototype

Click the Trigger prototypes link in the TRIGGERS column in the list of discovery rules, and click the Createtrigger prototype button in the upper right corner of the Trigger prototypes page to enter the Trigger prototype configuration page. As shown in figure 12-17 below.

Figure 12-17

The dependent triggerprototypes can be defined in the Dependencies tag. A trigger prototype can rely on another trigger prototype or a conventional trigger under the same discovery rule. A trigger prototype cannot rely on a trigger prototype under other discovery rules or a trigger created from a trigger prototype.

3. Graph prototype

Click the Graph prototypes link in the GRAPHS column in the list of discovery rules, and click the CreateGraph prototype button in the upper right corner of the Graph prototypes page to enter the Graph prototype configuration page. As shown in figure 12-18 below.

Figure 12-18

4. Host prototype

Click the Host prototypes link in the HOSTS column in the list of discovery rules, and click the CreateHost prototype button in the upper right corner of the Host prototypes page to enter the Host prototype configuration page. As shown in figure 12-19 below.

Figure 12-19

In Host prototypes, you can link templates and use LLD macro variables in host name, visible name, and groupprototypes. Hosts created by Host prototypes are prefixed with the name of the discovery rule, and can be deleted manually or automatically (based on the Keep lost resources period (in days) parameter setting defined in the discovery rule) in the list of Web front-end hosts. With the exception of the Enable option and host inventory, most options are read-only.

In the template Template VirtVMware provided in Zabbix, Host prototypes is defined in Discover VMware VMs and Discover VMware hypervisors discovery rules, which are used to discover and create monitoring hosts for virtual machines and VMwareESX servers, respectively, which can be used as a reference to better understand Host prototypes.

This article is from http://ustogether.blog.51cto.com/8236854/1929748. If you need to reprint it, please contact the author.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.