Zabbix Configurations


Rajesh Kumar

(Senior DevOps Manager & Principal Architect)

Rajesh Kumar — an award-winning academician and consultant trainer, with 15+ years’ experience in diverse skill management, who has more than a decade of experience in training large and diverse groups across multiple industry sectors.

Zabbix Hostgroup


Typical Zabbix hosts are the devices you wish to monitor (servers, workstations, switches, etc).

Creating hosts is one of the first monitoring tasks in Zabbix. For example, if you want to monitor some parameters on a server “x”, you must first create a host called, say, “Server X” and then you can look to add monitoring items to it.

Hosts are organized into host groups.

Host groups

Host groups are a collection of  hosts, The only thing worth mentioning is that Zabbix actually supports nested host groups. This is done using a naming convention.

Let’s say you have a host group called ‘Datacenter’. Then you want to introduce nested groups for your facilities in Warsaw and London. To do that simply create the following groups: ‘Datacenter/Warsaw’ and ‘Datacenter/London’.

Host groups

An unlimited number of groups can be applied to hosts and those hosts can belong to any template. It is good practice to have many groups associated with hosts so that it is easy to categorize them many different ways. For example, a host can belong to a group for the building name, a group of the host type, a group of host manufacture, a group of the network it resides on, and a group of any other information that may be shared among hosts.

Groups are also necessary for setting security permissions for user groups. Hosts must have groups or they cannot be assigned security permissions.

Host groups

Host groups

Host groups

In the Configuration → Host groups section users can configure and maintain host groups. A host group can contain both
- templates and
- hosts.

A listing of existing host groups with their details is displayed. You can search and filter host groups by name.

Host groups

  1. From the Zabbix menu Configuration go to Host groups.
  2. To add a new group, press the Create host group button and fill in a new name for the group in the Group name box.
  3. When you want to move existing servers to the new group then select from Other hosts | Group, an existing host or group and move them to the column on the left with the arrow buttons. Those are the servers you want to add to your new host group.
  4. Click the Save button at the bottom to save your changes.

Zabbix Templates


A template is a set of entities that can be conveniently applied to multiple hosts.

The entities may be:

  • items
  • triggers
  • graphs
  • applications
  • dashboards
  • low-level discovery rules
  • web scenarios


As many hosts in real life are identical or fairly similar so it naturally follows that the set of entities (items, triggers, graphs,…) you have created for one host, may be useful for many. Of course, you could copy them to each new host, but that would be a lot of manual work. Instead, with templates you can copy them to one template and then apply the template to as many hosts as needed.

When a template is linked to a host, all entities (items, triggers, graphs,…) of the template are added to the host. Templates are assigned to each individual host directly (and not to a host group).

Templates are often used to group entities for particular services or applications (like Apache, MySQL, PostgreSQL, Postfix…) and then applied to hosts running those services.

Another benefit of using templates is when something has to be changed for all the hosts. Changing something on the template level once will propagate the change to all the linked hosts.

Thus, the use of templates is an excellent way of reducing one's workload and streamlining the Zabbix configuration.


Everything set at the template level is inherited by hosts. The advantage of this design is that a large number of hosts can be applied to a template and they will all be monitored the exact same way. Modifications made to the template are applied to all hosts associated with the template, but customization to the template can be made at a single host without impacting the entire template.

Templates can be linked to each other to inherit attributes from the parent and keep a clean, traceable system. Below is a diagram of how templates can be linked to each other to inherit attributes.


Items are the ones that gather data from a host.

Once you have configured a host, you need to add some monitoring items to start getting actual data.

An item is an individual metric. One way of quickly adding many items is to attach one of the predefined templates to a host. For optimized system performance though, you may need to fine-tune the templates to have only as many items and as frequent monitoring as is really necessary.

In an individual item you specify what sort of data will be gathered from the host.


Triggers are logical expressions that “evaluate” data gathered by items and represent the current system state.

While items are used to gather system data, it is highly impractical to follow these data all the time waiting for a condition that is alarming or deserves attention. The job of “evaluating” data can be left to trigger expressions.

Trigger expressions allow to define a threshold of what state of data is “acceptable”. Therefore, should the incoming data surpass the acceptable state, a trigger is “fired” - or changes status to PROBLEM.

A trigger may have the following status:

Trigger status (the expression) is recalculated every time Zabbix server receives a new value that is part of the expression.

Most trigger functions are evaluated based on history data, while some trigger functions for long-term analytics, e.g. trendavg(), trendcount(), etc, use trend data.


There are several types of events generated in Zabbix:

  • trigger events - whenever a trigger changes its status (OK→PROBLEM→OK)
  • discovery events - when hosts or services are detected
  • autoregistration events - when active agents are auto-registered by server
  • internal events - when an item/low-level discovery rule becomes unsupported or a trigger goes into an unknown

Events are time-stamped and can be the basis of actions such as sending notification e-mail etc.

To view details of events in the frontend, go to Monitoring → Problems. There you can click on the event date and time to view details of an event.

Information flow in Zabbix

DevOpsSchool Community Networks

These platforms provide you the opportunity to connect with peers and industry DevOps leaders, where you can share, discuss or get information on latest topics or happenings in DevOps culture and grow your DevOps professionals network.

Build & Release
Build & Release
DevOps Group

Any Questions?

Thank You!

DevOpsSchool — Lets Learn, Share & Practice DevOps

Connect with us on | +91 7004 215 841 | 1800 889 7977

Next up: