You should have a Nagios Core 4.0 or newer server running with a few hosts and services configured already. You should also already be familiar with the relationship between services, commands, and plugins.

We can customize an existing command definition as follows:

If the validation passes and the server restarts successfully, we should now be able to use the check_http_altport command, which is based on the original check_http command, in a service definition.

The configuration we added to the preceding commands.cfg file reproduces the command definition for check_http but changes it in the following two ways:

The check_http_altport command can now be used as a check command in the same way a check_http command could be used. For example, a service definition that checks whether the sparta.example.net host is running an HTTP daemon on port 8080 might look something like this:

define service {
    use                  generic-service
    host_name            sparta.example.net
    service_description  HTTP_8080
    check_command        check_http_altport
}

This recipe's title implies that we should customize the existing commands by editing them in place and, indeed, this works fine if we really want to do things this way. Instead of copying the command definition, we could just add -p 8080 or other customization to the command line and change the original command.

However, this is bad practice in most cases, mostly because it could break the existing monitoring and be potentially confusing to other administrators of the Nagios Core server. If we have a special case for monitoring (in this case, checking a nonstandard port for HTTP), then it's wise to create a whole new command based on the existing one with the customizations we need.

Particularly, if you share monitoring configuration duties with someone else on your team, changing the command could break the monitoring for anyone who had set up services using the check_http command before you changed it, meaning that their checks would all start failing because port 8080 would be checked instead.

There is no limit to the number of commands you can define, so you can be very liberal in defining as many alternative commands as you need. It's a good idea to give them instructive names that say something about what they do as well as to add explanatory comments to the configuration file. You can add a comment to the file by prefixing it with a # character:

#
# 'check_http_altport' command_definition. This is to keep track of the
# servers that have administrative panels running on an alternative port
# to confer special privileges to a separate instance of Apache HTTPD
# that we don't want to confer to the one for running public-facing
# websites.
#
define command {
    command_name  check_http_altport
    command_line  $USER1$/check_http -H $HOSTADDRESS$ -p 8080 $ARG1$
}