In this recipe, we'll build on the basic web service monitoring established in the recipe Monitoring web services in this chapter and learn how to create a command that uses the check_http plugin to ensure that a particular string is included as part of an HTTP response.
By default, there's no Nagios Core command defined to use the plugin in this way, so the recipe will include defining a command before using it as part of a service check.
This may be necessary if we're monitoring a website on a server that may not necessarily return a 404 Not Found or similar error that will flag a WARNING or CRITICAL in Nagios; rather than merely checking if a document was found, we can check whether it matches a string to see if it resembles the particular document we expected.
This kind of setup is a nice complement to a suite of code unit tests for a website or web application.
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, and we'll check that it's returning the simple string example.net in its responses. 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.
You should set up basic HTTP monitoring for the host first, as established in the Checking web services recipe in this chapter, to make sure that there is connectivity between the monitoring server and the host, and that requests and responses are both working correctly with appropriate error codes.
We can set up a service check that includes an HTTP response content check 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 that directory instead.# cd /usr/local/nagios/etc/objects - Edit a suitable file containing command definitions and find the definition for the
check_httpcommand. In the default installation, this file iscommands.cfg. Thecheck_httpdefinition looks something like this:define command { command_name check_http command_line $USER1$/check_http -I $HOSTADDRESS$ $ARG1$ }
- Beneath the
check_httpdefinition, add a new command definition as follows:define command { command_name check_http_content command_line $USER1$/check_http -I $HOSTADDRESS$ -s $ARG1$ }
- Edit the file containing the definition for the host. The host definition might look something like this:
define host { use linux-server host_name sparta.example.net alias sparta address 192.0.2.21 }
- Beneath the definition for the host and beneath any other checks which might use
check_http, place a new service definition using our new command:define service { use generic-service host_name sparta.example.net service_description HTTP-content check_command check_http_content!example.net }
- 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 should begin making HTTP requests to monitor the service as check_http normally does, except that it will only return an OK state if the content of the website includes the string example.net. Otherwise, it will generate an alert and flag the service as CRITICAL, with a message like the following:
HTTP CRITICAL: HTTP/1.1 200 OK - string 'example.net' not found on 'http://192.0.2.21:80/' - 453 bytes in 0.006 second response time
One of the many options for check_http is -s, short for --string, which takes a single argument specifying a string that must occur in the content for the service check to return an OK state.
When the HTTP response is received, check_http examines the text in the response to see if it matches the string specified, on top of its usual behavior of flagging WARNING or CRITICAL states for connectivity or timeout problems.
Note that, in order to make this work, it was necessary to define a new command that uses the first argument (in this case, the string example.net) as the value for the -s option to check_http. The full command line executed would look something like the following one:
# /usr/local/nagios/libexec/check_http -H sparta.example.net -s example.net
The check_http plugin allows considerably more than single string checks; if it's necessary to test for the presence of a regular expression in the content, this can also be done using the -r or --regex options. We could define a command to check for regular expressions like this:
define command {
command_name check_http_regex
command_line $USER1$/check_http -I $HOSTADDRESS$ -r $ARG1$
}If it's necessary to check that a particular regular expression doesn't match the content, this is possible by adding the --invert-regex flag:
define command {
command_name check_http_noregex
command_line $USER1$/check_http -I $HOSTADDRESS$ -r $ARG1$ --invert-regex
}A service check using this command would return CRITICAL if the response was found to match the pattern provided as the first argument to a check_command directive.
Other similar options include -e or --expect, which allows specifying a comma-separated set of strings, at least one of which must match the content for the check to pass.
- Creating a new host, Chapter 1, Understanding Hosts, Services, and Contacts
- Creating a new service, Chapter 1, Understanding Hosts, Services, and Contacts
- Creating a new command, Chapter 2, Working with Commands and Plugins
- Customizing an existing plugin, Chapter 2, Working with Commands and Plugins
- The Monitoring web services recipe in this chapter