Navigate to Configuration | Maintenance and click on Create maintenance period. In the resulting form, fill in these values:

• Name: Enter Normal maintenance
• Maintenance type: With data collection
• Active since: Make sure this is set to the start of your current day or earlier
• Active till: Make sure this is set to a year or so in the future
• Description: Enter we keep data during this maintenance

What's that? Are we really creating a year-long maintenance period? Not really. Switch to the Periods tab:

Here, the Zabbix terminology is a bit confusing. The main tab has since-till fields, which allow us to set what we could call the main period. The Periods tab allows us to add individual periods, which we can call subperiods. Any maintenance entry in Zabbix must have at least one subperiod defined. Maintenance in Zabbix is active when the main period overlaps with subperiods. Let's repeat that:

We should not add a maintenance entry without any sub periods defined.

No sub periods are defined here yet, so let's click on New.

To keep things simple here, let's add a one-time period. In the Date field, set the date and time to the current values. We can leave the Maintenance period length at the default, which is 1 hour.

When you're done, click on the small Add link after the Maintenance period section—do not click on the Add button yet. Only after clicking on that small Add link should you click on the Add button, an error should appear:

That didn't seem to work too well—apparently, a maintenance entry without any hosts or groups assigned to it cannot be created. Switch to the Hosts and groups tab. For our first maintenance period, select the Linux servers from the Host groups box, and choose A test host from the Hosts box. Then, click on the Add button, but this time not the small Add link, as shown in the following screenshot, as that one is used to add extra tag lines:

You may freely add any number of hosts and host groups, and they may overlap. Zabbix will correctly figure out which hosts should go into maintenance. The maintenance entry should appear in the list:

The reminder to click on the small Add link was repeated several times for a reason—it is too easy to forget to click on it and actually miss your changes in some cases. For example, if you were adding the second sub period and forgot to click on the small link, it would be silently discarded. Watch out for similar traps in other forms!

As you can also see in the preceding screenshot, when you click the filter on top of the page, it is now possible to filter the maintenance periods in a more easy way by selecting the state of the maintenance periods you would like to see.

With the maintenance entry added, let's try to see the effect this has on several sections in the frontend. In the console, run the following command:

$ cat /dev/urandom | md5sum

Navigate to Monitoring | Problems. Select A test host from the Hosts selection box and make sure you also mark the Show suppressed problems option:

Wait for the trigger to fire. When it shows up, look at the Host column—this time, there's an orange wrench indicator. This shows us that maintenance is currently active for this host. Move the mouse cursor over this indicator:

The message shows the name of the maintenance we used—normal maintenance. It also tells us that this maintenance is configured to keep collecting data, and below, that the description of the maintenance is shown. This allows us to easily inform other users why this maintenance is taking place. Still on the problem page, look at the filter. Notice how the Show suppressed problems checkbox was marked by us. Unmark it and click on Apply. All problems for A test host should disappear—well, from this view at least. To avoid being confused later, mark that checkbox and click on Apply again. Remember, most filter options are remembered between visits to a specific page, so we will not see hosts in maintenance in this view later if we leave it unmarked.

Let's check how another page looks when a host is in maintenance. Navigate to Monitoring | Dashboard and click on Edit dashboard. Next, click on the gear in the top-right corner of the Problems widget and also check the Show suppressed problems option here, then click Apply:

Note that we can choose many more options for our widget. We can even choose to only show problems for certain hosts or host groups or even only those where the trigger is tagged with a certain tag, or decide to not show problems with a certain severity level.

The host that's under maintenance is denoted here in the same way. Again, moving the mouse cursor over the orange icon will reveal the maintenance name, type, and description. 

The maintenance status can also be seen in other frontend sections. We will review some of them in Chapter 21, Visualizing  Data with Graphs and Maps.

We created and checked one maintenance entry. During this maintenance, data from our host was still collected, and triggers were checking that data. The status was shown in the frontend, and we could choose to hide hosts that were in maintenance. Now let's try something different—maintenance that also stops data from being collected in Zabbix.