Creating a new HTTP service

In this recipe, we'll create a new service to check on an existing host. Specifically, we'll check our sparta.example.net server to verify that it's responding to HTTP requests on the usual HTTP TCP port of 80. To do this, we'll be using a predefined command called check_http, which in turn uses one of the standard set of Nagios Core plugins, also called check_http. If you don't yet have a web server defined as a host in Nagios Core, you may like to try the recipe Creating a new network host in this chapter first.

After we've done this, not only will our host be checked for a PING response with its check_command, but Nagios Core will also run a periodic check to ensure that a HTTP service on that machine is responding to requests on the same host.

Getting ready

You'll need a working Nagios Core 4.0 or greater installation with a web interface, all the Nagios Plugins installed, and at least one host defined. If you need to set up a host definition for your web server first, you might like to read the Creating a new network host recipe in this chapter, for which the requirements are the same.

It would be a good idea to test that the Nagios Core server is actually able to contact the web server first, so we know that the test we're about to set up should succeed. The telnet(1) tool is a fine way to test that a response comes back from the TCP port 80 as we would expect from a web server:

user@olympus:~$ telnet 192.0.2.21 80
Trying 192.0.2.21...
Connected to 192.0.2.21.
Escape character is '^]'.

How to do it...

We can create the service definition for sparta.example.net as follows:

1. Change to the directory containing the file in which the sparta.example.net host is defined and edit it:

   # cd /usr/local/nagios/etc/objects
   # vi sparta.example.net.cfg
   

2. Add the following to the end of the file, substituting the value of the host's host_name directive:

   define service {
       host_name              sparta.example.net
       service_description    HTTP
       check_command          check_http
       max_check_attempts     3
       check_interval         5
       retry_interval         1
       check_period           24x7
       notification_interval  60
       notification_period    24x7
       contacts               nagiosadmin
   }

3. Reload the configuration:

   # /etc/init.d/nagios reload
   

If the server restarted successfully, the web interface should now show you a new service under the Services section and a PENDING state as the service awaits its first check:

Within a few minutes, the service's state should change to OK once the check has run and succeeded with an HTTP/1.1 200 OK response, or a similar response:

If the check had problems, perhaps because the HTTP daemon isn't running on the target server, the check may show CRITICAL instead. This probably doesn't mean that the configuration is broken; it more likely means that the network or web server isn't working:

How it works...

The configuration we've added adds a simple service check definition for an existing host, to check up to three times whether the HTTP daemon on that host is responding to a simple HTTP/1.1 request. If Nagios Core can't get a response to its test, it will flag the state of the service as CRITICAL and will try again two more times before sending a notification. The service will be visible in the Nagios Core web interface, we can check its state any time, and Nagios Core will continue testing the server on a regular basis and flagging whether the checks were successful or not.

It's important to note that the service is like a property of a particular host; we define a service to check for a specific host; in this case, the sparta.example.net web server. That's why it's important to get the definition for host_name right.

The directives we defined in the preceding configuration are as follows:

• host_name: This references the host definition for which this service should apply. This will be the same as the host_name directive for the appropriate host.
• service_description: This is the name of the service itself, something human-recognizable that will appear in alerts and in the web interface for the service. In this case, we've used HTTP.
• check_command: This references the command that should be used to check the service's state. Here, we're referring to a command defined in Nagios Core's default configuration called check_http, which refers to a plugin of the same name in the Nagios Core Plugins set.
• max_check_attempts: This defines the number of times Nagios Core should attempt to recheck the service after finding it in a problematic state.
• check_interval: This defines how long Nagios Core should wait between checks when the service is OK or after the number of checks given in max_check_attempts has been exceeded.
• retry_interval: This defines how long Nagios Core should wait between retrying checks after finding them in a problematic state.
• check_period: This references the time period during which Nagios Core should run checks of the service. Here, we've used the sensible 24x7 time period, as defined in Nagios Core's default configuration. Note that this can be different from notification_period; we can check the service's status without necessarily notifying a contact.
• notification_interval: This defines how long Nagios Core should wait between resending notifications when a service is in a state other than OK.
• notification_period: This references the time period during which Nagios Core should send notifications if it finds a host in a state that is not OK. Here, we've again used 24x7, but for some less critical services it might be appropriate to use a time period such as workhours.

Note that we added the service definition in the same file as defining the host, directly after it. We can actually place the definition anywhere we like, but this happens to be a good way to keep things organized.

There's more...

The service we've set up to monitor on sparta.example.net is an HTTP service, but that's just one of the many possible services we could monitor on our network. Nagios Core defines many different commands for its core plugin set, such as check_smtp, check_dns, and others; all these commands, in turn, point to the programs that actually perform the check and return the results to the Nagios Core server to be dealt with. The important thing to take away from this is that a service can monitor pretty much anything and there are hundreds of plugins available for common network monitoring checks available on the Nagios Exchange website (http://exchange.nagios.org/).

There are a great deal more possible directives for services. In practice, we often want to have a service template object with common values, and then extend it for each service we need to check. This allows us to define values that we might want for a number of services, such as how long they should be in a CRITICAL state before a notification event takes place and someone gets contacted to deal with the problem.

One such template that Nagios Core's default configuration defines is called generic-service and we can use it as a basis for our new service by referring to it with the use keyword:

define service {
    use                    generic-service
    host_name              sparta.example.net
    service_description    HTTP
    check_command          check_http
}

This may work well for you, as there are a lot of very sensible default values set by the generic-service template, which makes things a lot easier. We can inspect these values by looking at the template's definition at /usr/local/nagios/etc/objects/templates.cfg. This is the same file that includes the generic-host definition that we may have used earlier.

See also

• The Creating a new servicegroup section in this chapter
• Specifying how frequently to check a service, Chapter 3, Working with Checks and States
• Scheduling downtime for a host or service, Chapter 3, Working with Checks and States
• Monitoring web services, Chapter 5, Monitoring Methods