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. You should also understand the basics of how hosts and services relate, which is covered in the recipes in Chapter 1, Understanding Hosts, Services, and Contacts.

An appropriate first step is making sure that the services we intend to check are accessible from the monitoring server running Nagios Core. This can be done from the command line using an HTTP client such as curl or wget:

$ wget http://sparta.example.net/
$ curl http://sparta.example.net/

The check_http plugin binary could also be called directly to test this connectivity; we'd be hoping for an HTTP OK response with a code of 200:

# sudo -s -u nagios
$ /usr/local/nagios/libexec/check_http -I sparta.example.net
HTTP OK: HTTP/1.1 200 OK - 453 bytes in 0.004 second response time |time=0.004264s;;;0.000000 size=453B;;;0

Optionally, we can check HTTPS the same way if the plugins were compiled with OpenSSL available, adding the -S option for the plugin:

# sudo -s -u nagios
$ /usr/local/nagios/libexec/check_http -S -I sparta.example.net
HTTP OK: HTTP/1.1 200 OK - 453 bytes in 0.058 second response time |time=0.057836s;;;0.000000 size=453B;;;0

Both may require the installation of a default page to be served by the host, probably something like index.html, depending on the web server software.

Once HTTP connectivity to the host from the monitoring server is verified as working with appropriate responses, we can proceed to add our service check.

We can add web service checks for our host as follows:

With this done, a new service called HTTP, and optionally one called HTTPS, will be added for the sparta.example.net host and HTTP requests will be made from the server regularly, reporting if connectivity fails or a response comes back with an unexpected status. These services will both be visible in the Services section of the web interface.

It's important to note that, by itself, the setup given here won't check the validity of your secure certificates; it will simply check if it can make an encrypted connection.

The preceding configuration uses check_http as a plugin to make scheduled requests of the sparta.example.net server. By default, the root or default page is requested, so the request takes the following form:

GET / HTTP/1.0
User-Agent: check_http/v2.0.3 (nagios-plugins 2.0.3)
Connection: close
Accept: */*

The plugin awaits a response, and then returns a status based on the following criteria:

Inspecting the command definition for the default check_http command in /usr/local/nagios/etc/objects/commands.cfg gives some insight into how it uses the plugin of the same name:

define command {
    command_name  check_http
    command_line  $USER1$/check_http -I $HOSTADDRESS$ $ARG1$
}

This uses three Nagios Core macros:

There are a great many other switches available for the check_http plugin; a list of them with a short explanation for each is available by entering the command with --help.

# /usr/local/nagios/libexec/check_http --help

One particularly useful option is -u, which allows us to request specific URLs other than the default index document from the server. This can be useful if we're in a situation that requires setting up checks for more than one page on a site, which can be a nice supplement to code unit testing when a site is deployed or updated.

For example, if we wanted to check that three pages were returning 200 Found responses: about.php, products.php, and contact.php, we could set up a new command like the following to check a specific page:

define command {
    command_name  check_http_page
    command_line  $USER1$/check_http -I $HOSTADDRESS$ -u $ARG1$
}

This would allow us to make three service checks like the following using the new command:

define service {
    use                  generic-service
    host_name            sparta.example.net
    service_description  HTTP-about
    check_command        check_http_page!/about.php
}
define service {
    use                  generic-service
    host_name            sparta.example.net
    service_description  HTTP-products
    check_command        check_http_page!/products.php
}
define service {
    use                  generic-service
    host_name            sparta.example.net
    service_description  HTTP-contact
    check_command        check_http_page!/contact.php
}

These service checks would run the same way as the one demonstrated in the recipe, except they would each request a specific page. Note that the leading slashes on the URLs are required.

Similarly, the -H option allows you to specify hostnames, which is helpful on servers hosting more than one site. This could be done by setting up a command like the following one:

define command {
    command_name  check_http_host
    command_line  $USER1$/check_http -I $HOSTADDRESS$ -H $ARG1$
}

This would allow you to check two sites on the same host, http://www.example.net/ and http://dev.example.net/, in separate service checks:

define service {
    use                  generic-service
    host_name            sparta.example.net
    service_description  HTTP-www
    check_command        check_http_host!www.example.net
}
define service {
    use                  generic-service
    host_name            sparta.example.net
    service_description  HTTP-dev
    check_command        check_http_host!dev.example.net
}

It's worth noting that the check_http request will show up in your server logs with its regular requests. If you're concerned about this distorting statistics, or appearing unwanted in reports, it may be easiest to filter it out using its User-Agent header value, which includes the string check_http.