Adding an item or any other entity to a template is virtually identical to the same operation performed on a regular host. This is especially true for items. As you already know, item keys are the basic building blocks of the Zabbix monitoring pipeline, and you don't have to specify any kind of address or interface when you create them as Zabbix will take this kind of information from the host the item is assigned to. This means that when you create items for a template, you are effectively creating items for an ideal host that will be later applied to real ones once you have linked the template to the hosts you want to monitor.
Note
Templates, just like hosts, are essentially collections of items, triggers, and graphs. Since many of the concepts that we will explore apply equally to items, triggers, and graphs, for the rest of the chapter we'll use the term entity to refer to any of the three types of objects. In other words, you can understand an item, trigger, or graph every time you read entity, and items, triggers, and graphs when you read entities as a collective term.
This applies to other types of entities as well, but as they always reference one or more existing items, you need to make sure that you select the items belonging to the right template and not to a regular host:
This may seem obvious, but it is far too easy to select the Items, Graphs, or Screens contained in the template using the links at the top of the window.
The main difference between template entities and host entities, especially when it comes to triggers, is that with template entities, macros are quite useful to make trigger and graph names or parameters more expressive and adaptable.
We can summarize the entities that can be grouped in a template as:
- Items
- Triggers
- Graphs
- Applications
- Screens
- Low-level discovery rules
- Web scenarios (since Zabbix 2.2)
It's important to also bear in mind that to be able to link a template to a host, the host itself needs to have items with unique names. Then, if the host already contains the template's items or a subset of them, we need to sort out the duplicates issue.
As you've already seen in Chapter 6, Managing Alerts, macros are very useful to make a message general enough for it to be applied to a wide range of events. It will be the Zabbix server's job to substitute all the macros in a message with the actual content based on the specific event it's handling. Since an action message is effectively a template that has to be applied to a particular event, it's easy to see how the same concept is essential for the effectiveness of host templates. What changes is the context; while an event has a context that is quite rich since it can reference a trigger and one or more different items and hosts, the context of a simple, regular host is admittedly more limited. This is reflected in the number of macros available, as they are just a handful:
|
Macro name |
Macro translates to |
Notes |
|---|---|---|
|
|
This will be identical to either | |
|
|
This must correspond to the host's fully qualified domain name as defined in the domain's DNS server. | |
|
|
This is the main host identifier. It must be unique for the specific Zabbix server. If using an agent, the same name must be present in the agent's configuration on the host. | |
|
|
A host can have more than one IP address. You can reference them using | |
|
|
This will be the name visible in lists, maps, screens, and so on. |
To better clarify the differences between the various {HOST.*} macros, let's see an example host configuration:
In this case, {HOST.HOST} will resolve to ZBX Main, {HOST.NAME} to Main Zabbix Server, {HOST.IP} to 127.0.0.1, and {HOST.DNS} to zabbix.example.com. Finally, since the Connect to option is set to IP, {HOST.CONN} will resolve to 127.0.0.1 as well.
The most obvious use of these macros is to make trigger and graph names more dynamic and adaptable to the actual hosts they will be used into. Since a graph's name is displayed as a header when viewing the graph, it's vital to distinguish between different graphs of the same type belonging to different hosts, especially when they are displayed together in a screen, as explained in Chapter 5, Visualizing Data.
A less obvious use of these macros is inside an item's key definition. We touched briefly on external scripts in Chapter 4, Collecting Data, and you'll meet them again in the next chapter, so we won't get into too much detail about them here. It would suffice to say that from an item creation point of view, all you need to know about an external script is its name and any parameters you may need to pass in order to execute it correctly.
Since external scripts, as is their nature, don't share any information with the rest of Zabbix other than the arguments they are passed and their return value, it's often essential to include the host's IP address or hostname as one of the arguments. This ensures that the script will connect to the right host and collect the right data. A single, well-configured script can perform the same operation on many different hosts thanks to the template systems and macros, such as {HOST.CONN}, {HOST.IP}, and so on.
Take, for example, a script that checks whether a particular application is alive using a custom protocol. You could have an external script, say app_check.sh, which takes a host name or IP address as an argument, connects to it using the application's protocol, and returns 1 if it's alive and well and 0 if the check fails. Your template item's key would look similar to the following screenshot:
In these cases, using a macro as the argument to the item's key is the only way to make an external check for a part of a template and is useful for any regular host.
Another example would be that of a bunch of Zabbix hosts that don't represent regular operating system machines, physical or virtual, but single applications or single database instances. In a scenario like this, all the application hosts would share the same connections and interfaces—those of the actual server hosting the applications—and they would be linked to a template holding only items relevant to application-level (or database-level) measurements. To keep things simple, let's say that you have an application server (Alpha) hosting three different applications:
- A document archival facility (doku)
- A customer survey form manager (polls)
- A custom, internal microblogging site (ublog)
For each of these applications you are interested in, by and large, take the same measurements:
- The number of active sessions
- The amount of memory consumed
- The number of threads
- The network I/O
- The number of connections to the database
Again, for simplicity's sake, let's say that you have a bunch of external scripts that, given an IP address and an application name, can measure exactly the preceding metrics. External script keys tend to be easy to read and self-explanatory, but all of this can be equally applied to JMX console values, Windows performance counters, database queries, and any other kind of items.
One way to monitor this setup is to create only one host, Alpha and, in addition to all the regular OS- and hardware-monitoring items, a number of items dedicated to application measurements, which are repeated for each one of them. This can certainly work, but if you have to add a new application, you'll need to create all the items, triggers, and graphs related to it even if they differ from the rest by just the application's name.
As that is the only difference in an otherwise identical collection of entities, a more flexible solution would be to split the monitoring of every application to a different host and apply a common template.
Note
A host, from Zabbix's point of view, is just a collection of entities with one or more connection interfaces. It doesn't have to be an actual, physical (or virtual!) machine with a regular operating system. Any abstract but coherent collection of metrics and a means to retrieve them can be configured as a host in Zabbix. Typical examples are applications, database instances, and so on.
Instead of creating many similar items, triggers, and so on for the host, Alpha, you would create a custom application template and fill it with items that would look similar to the following screenshot:
You can then create one host for each application, with Alpha's IP address as the connection interface, and with the application's name as the hostname. Linking the template you just created to the hosts would give you the same basic results as before but with much more flexibility; adding an application to be monitored now is a simple matter of creating a host and linking it to the correct template. If you move an application from one server to another, you just need to update its IP address. If you put all these application hosts in a separate group, you can even grant access to their monitoring data to a specific group of users without necessarily giving them access to the application server's monitoring data. And, it goes without saying that adding, deleting, or modifying an entity in the template apply immediately to all the monitored applications.
A special class of macros is user-defined, template- and host-level macros. You can configure them in the Macros tab of every host or template creation and administration form. They are quite simple as they only provide a translation facility from a custom label to a predefined, fixed value. The following screenshot shows this:
When used in a template, they prove quite useful in defining common thresholds for triggers, so if you need to modify a bunch of time-out triggers, you can just modify the {$NODATA} macro instead of changing every single trigger that uses it. User-defined macros can be used everywhere built-in macros can be used.
Note
If a user macro is used in items or triggers in a template, it is better to add that macro to the template in any case even if is defined on a global level. Doing so once you've exported your template to XML, you can freely import it into another system without taking the care to have all the user macros properly configured.
The usefulness is even greater when used in connection with nested templates, as we'll see in a short while.
The most common use cases of global and host macros are:
- Using all the advantages of a template with host-specific attributes: port numbers, filenames, accounts, and so on
- Using global macros for one-click configuration changes and fine-tuning
A practical example of macro usage can be the use of host-level macros in the item keys, such as Status of SSH daemon:
net.tcp.service[ssh,,{$SSH_PORT}]This item can be assigned to multiple hosts once you've defined at the host level the value of {$SSH_PORT}. By doing so, you're generalizing a custom item where $SSH_PORT may change across servers; this can be done for HTTP services too, among others.