In this recipe, we'll adjust the configuration for a service that has been bugging us with notifications late at night. We'll arrange to keep checking this host, sparta.example.net, on a 24x7 basis, but we'll prevent it from sending notifications outside of work hours using two of the predefined time periods in the default Nagios Core configuration.
You should have a Nagios Core 4.0 or newer server with at least one host configured already. We'll use the example of sparta.example.net, a host defined in its own file.
We can define the check_period and notification_period for our host as follows:
- Change to the objects configuration directory for Nagios Core. The default is
/usr/local/nagios/etc/objects. If you've put the definition for your host in a different file, move to its directory instead.# cd /usr/local/nagios/etc/objects - Edit the file containing your host definition and find the definition within the file:
# vi sparta.example.net.cfgThe host definition may look something like this:
define host { use linux-server host_name sparta.example.net alias sparta address 192.0.2.21 } - Add or edit the value for the
check_perioddirective to24x7:define host { use linux-server host_name sparta.example.net alias sparta address 192.0.2.21 check_period 24x7 } - Add or edit the value for the
notification_perioddirective toworkhours:define host { use linux-server host_name sparta.example.net alias sparta address 192.0.2.21 check_period 24x7 notification_period workhours } - Validate the configuration and restart the Nagios Core server:
# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg # /etc/init.d/nagios reload
With this done, Nagios Core will run its check of the host all the time (24 hours a day, 7 days a week), including logging UP and DOWN states, showing them in the web interface, and reporting, but will only send notifications to the nominated contact for the host during work hours, that is from 9 a.m. to 5 p.m., Monday to Friday, by default.
The preceding configuration changed two properties of the host object type to effect the changes we needed:
check_period: This property defines the time periods during which the host should be checked; we chose the predefined period24x7, meaning the checks against the host are always to be run, regardless of the time of day or night.notification_period: This property defines the time periods during which the host should send notifications to the appropriate contact; we chose the predefined periodworkhours, meaning that notifications will only be sent from 9 a.m. to 5 p.m., Monday to Friday.
Exactly the same configuration could be applied to a service, rather than a host:
define service {
...
check_period 24x7
notification_period workhours
}The two time periods to which this new configuration refers are themselves defined in the Nagios Core configuration. The ones we've used, 24x7 and workhours, are standard time periods included in the defaults, kept in the file /usr/local/nagios/etc/objects/timeperiods.cfg. The definition for workhours, for example, looks like this:
define timeperiod {
timeperiod_name workhours
alias Normal Work Hours
monday 09:00-17:00
tuesday 09:00-17:00
wednesday 09:00-17:00
thursday 09:00-17:00
friday 09:00-17:00
}The ones we've used here are just examples of common time periods. We can define time periods ourselves with great precision; see the recipe Creating a new time period in Chapter 1, Understanding Hosts, Services, and Contacts for details on how to do this.
The distinction between the two directives is very important. Under most circumstances, we will want a check_period that corresponds to all the times for services that are up day and night, because it means we can retain information about the long-term uptime for the service. Keeping a distinct notification_period simply allows us to control when notifications should be sent, perhaps because they would otherwise go to a pager and wake up a grumpy systems administrator for a relatively unimportant system!
It's valid Nagios Core configuration to set a check_period for a reduced time period, for example, workhours. However, you shouldn't need to do this unless your host is actually going to be down outside these hours. In most cases, it's appropriate to use the 24x7 time period as a value for the check_period.