Although we have already looked at some data that was provided by the frontend, we should get a bit more familiar with it before attempting some more configuration tasks.

The configuration steps will be followed by verifying the results in the Monitoring quickstart section. We will then explain some generic item terms that are used in Zabbix and their uses. Items, being the basis of information gathering, have a fair amount of configuration possibilities.

In your browser, go to the URL that contains the IP of your Zabbix setup, as mentioned in the following steps. Zabbix should be properly configured now and manageable from the UI:

1. Open Zabbix's root URL (http://<server_ip_or_name>/zabbix) and log in again if you have been logged out. You should now see a pretty empty dashboard with a little information.
2. Click on the entries in the top menu...

Now that we have a basic understanding of the frontend navigation, it's time to look at the basics of data gathering in Zabbix Items. In general, anything you want to gather data about will eventually go into an item.

If items are so important in Zabbix, we should create some. After all, if no data retrieval is possible without items, we can't monitor anything without them. To get started with item configuration, open Configuration | Hosts. If it's not selected by default, choose All in the Group drop-down menu (in the top-right corner). This is a location...

We have now configured various things in the Zabbix frontend, including data gathering (Item), threshold definition (Trigger), and instructions on what to do if a threshold is exceeded (Action). But how does it all work together? The flow of information between Zabbix entities can be non-obvious at first glance. Let's look at a schematic showing how the pieces go together:

In our Zabbix server installation, we created a host (A test host), which contains an item (CPU load). A trigger references this item. Whenever the trigger expression matches the current item value, the trigger switches to the PROBLEM state. When it ceases to match, it switches back to the OK state. Each time the trigger changes its state, an event is generated. The event contains details of the trigger state change: when it happened and what the new state is. When configuring...

Right, so we configured sending email. But it's not very interesting until we actually receive some notifications. Let's increase the load on our test system. In the console, launch the following:

$ cat /dev/urandom | md5sum

This grabs a pseudo random, never-ending character stream and calculates its MD5 checksum, so system load should increase as a result. You can observe the outcome as a graph—navigate to Monitoring | Latest data and click on Graph for our single item again.

Notice how the system load has climbed. If your test system can cope with such a process really well, it might not be enough—in such a case, you can try running multiple such MD5 checksum calculation processes simultaneously.

Allow 3 minutes to pass and there should be a popup in the upper-right corner, accompanied by a sound alert:

There is one of the...

We rushed through the configuration of our simple item, so you might have gotten curious about the parameters we didn't change or talk about. Let's take a quick look at what can be monitored and what we can configure for each item.

Zabbix can monitor quite a wide range of system characteristics. Functionally, we can split them into categories, while technically, each method used corresponds to an item type.

Let's take a look at the generic categories that we can keep an eye on. Of course, this is not an exhaustive list of things to monitor—consider this as an example subset of interesting parameters. You'll soon discover many more areas to add in your...

So far, we have navigated to a host or its items and other entities by going to specific pages in the frontend and then looking up the group and host. This is a convenient enough method in smaller installations, and it's also what we will mostly use in this book. In a larger installation, navigating like this could be very time-consuming, thus, a feature called global search becomes very useful. Actually, many users almost completely skip the classic navigation method and use search exclusively.

The global search field is available in the upper right corner of the Zabbix frontend. In there, type a single letter, a. Anything entered here is matched against the beginnings of host-names, and the results are shown in a drop-down. In our case, A test host matches:

You can choose one of the drop-down entries with your keyboard or mouse, or search using your...

This was the chapter where we finally got some real action: monitoring an item, creating a trigger, and getting a notification on that trigger. We also explored the Zabbix frontend a bit and looked at basic item parameters. Let's review what basic steps were required to get our first alert:

• We started by creating a host. In Zabbix, everything to be monitored is attached to a logical entity called a host.
• Next, we created an item. Being the basis of information gathering, items define parameters about monitored metrics, including what data to gather, how often to gather it, how to store the retrieved values, and other things.
• After the item, we created a trigger. Each trigger contains an expression that is used to define thresholds. For each trigger, a severity can be configured as well. To let Zabbix know how to reach us, we configured our email settings. This included...

1. Name the 5 severity levels in Zabbix.
2. Can Zabbix send messages to different users or groups, and where do we configure this?
3. Does Zabbix allow items to be pre-processed before it saves them into the database?

Read the following articles for more information:

• Setting time periods: https://www.zabbix.com/documentation/4.0/manual/appendix/time_period
• Items: https://www.zabbix.com/documentation/4.0/manual/config/items
• VMware monitoring item keys: https://www.zabbix.com/documentation/4.0/manual/config/items/itemtypes/simple_checks/vmware_keys