(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.
WHAT IS A "HOST"?
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 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’.
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.
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.
A template is a set of entities that can be conveniently applied to multiple hosts.
The entities may be:
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:
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.
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.
DevOps |
Build & Release |
DevOps |
Build & Release |
DevOpsSchool |
DevOps Group |
BestDevOps.com |
DevOpsSchool — Lets Learn, Share & Practice DevOps
Zabbix
Session-6-Zabbix-Permissions