Monitoring other system’s operations using Nagios

Nagios also offers plugins for many other operations that are common to daily system monitoring and activities; this section covers only a few of them. It is recommended that you look for the remaining commands in both the Nagios Plugins package as well as on the Nagios Exchange website.

Checking for updates with APT

Many Linux distributions use Advanced Packaging Tool (APT) for handling package management (refer to This tool is used by default on Debian and its derivatives such as Ubuntu.

It allows the handling of upgrades and download of packages. It also allows the synchronization of package lists from one or more remote sources.

Nagios provides a plugin that allows you to monitor if any upgrades are available and/or perform upgrades automatically. The syntax and the description of the options are as follows:

check_apt [-d|-u|-U [<opts>]] [-n] [-t timeout]           
          [-i <regex>] [-e <regex>] [-c <regex>]



-u, --update

Perform an apt update operation prior to other operations


Perform an apt upgrade operation


Perform an apt dist-upgrade operation

-n, --no-upgrade

Do not run upgrade or dist-upgrade; useful only with -u

-i, --include

Include only packages matching a regular expression

-c, --critical

If any packages match a regular expression, a critical state is returned

-e, --exclude

Exclude packages matching a regular expression

If the -u option is specified, the command first attempts to update apt package information. Otherwise, the package information currently in cache is used. If the -U or -d option is specified, the specified operation is performed. If -n is specified, only an attempt to run the operation is made, without actually upgrading it performs monitoring (and not upgrade) the activities system. The plugin might also be based on daily apt updates/upgrades and only monitor.

The following is a command definition for a simple dist-upgrade, as well as for monitoring available packages and issuing a critical state if the Linux images are upgradeable (that is, if newer packages exist). However, this command does not perform the actual upgrades:

  define command 
    command_name  check_apt_upgrade 
    command_line  $USER1$/check_apt -u -d 
  define command 
    command_name  check_apt_upgrade2 
    command_line  $USER1$/check_apt -n -u  
       -d -c "^linux-(image|restrict)" 

Monitoring UPS status

Another useful feature is that of Nagios being able to monitor the UPS status over the network. This requires the machine with the UPS to have the Network UPS Tools package (refer to installed and running, so that it is possible to query the UPS parameters. It is also possible to monitor local resources using the same plugin. The syntax and the description of the options are as follows:

check_ups -H host -u ups [-p port] [-v variable] [-T]              
                         [-w <warn time>] [-c <crit time>] [-t <timeout>]



-u, --ups

The name of the UPS to check

-p, --port

The port to use for TCP/IP connection; defaults to 3493

-T, --temperature

Report the temperature in Celsius degrees

-v, --variable

Variable to output; one of LINE, TEMP, BATTPCT, and LOADPCT

The name of the UPS is usually defined in the ups.conf file on the machine that the command is connecting to. The plugin will return an ok state if the UPS is calibrating or running on AC power. A warning state is returned if the UPS claims to be running on batteries, and a critical state is returned in the case of a low battery or if the UPS is off.

The following is a sample definition of a check command that gets the UPS name passed as an argument:

  define command 
    command_name  check_ups 
    command_line  $USER1$/check_ups -H $HOSTADDRESS$ -u $ARG1$ 

Gathering information from LM sensors

This is a Linux-specific plugin that uses the lm-sensors package (refer to to monitor hardware health.

The check_sensors command issues an unknown status if the underlying hardware does not support health monitoring or if the lm-sensors package is not installed, a warning status if a non-zero error is returned by the sensors command, and a critical status if the string ALARM is found within the output from the command.

The plugin does not take any arguments and simply reports information based on the sensors command.

The command definition is as follows:

  define command 
    command_name  check_sensors 
    command_line  $USER1$/check_sensors 

Using the dummy check plugin

Nagios also offers a dummy checking plugin. It simply takes an exit code from an argument and returns it. It is useful for testing dependencies between hosts and/or services, verifying notifications and can also be used for a service that will be measured using passive checks only. The syntax of this plugin is as follows:

check_dummy <exitcode> [<result string>]

The result string object type specifies a message that will be returned and shown in Nagios UI. If it is not specified, the OK, WARNING, CRITICAL, or UNKNOWN statuses are returned as messages, based on the exit code to be returned.

The following is a sample command definition that returns an ok status without an additional detailed message:

  define command 
    command_name  check_dummy_ok 
    command_line  $USER1$/check_dummy 0 

The following example also shows how to return a critical status with a more detailed message:

  define command 
    command_name  check_dummy_critical 
    command_line  $USER1$/check_dummy 2 "Dummy result message" 

Manipulating other plugins’ output

Nagios offers an excellent plugin that simply invokes other checks and converts their status accordingly. This might be useful when a failed check from a plugin is actually an indication that the service is working correctly. This can, for example, be used to make sure that non-authenticated users can’t send e-mails while valid users can. The syntax and the description of the options are as follows:

negate [-t timeout] [-o|-w|-c|-u state] <actual command to run> 



-o, --ok

State to return to when the actual command returns an ok state

-w, --warning

State to return to when the actual command returns a warning state

-c, --critical

State to return to when the actual command returns a critical state

-u, --unknown

State to return to when the actual command returns an unknown state

The states to return can either be specified as an exit code number or as a string. If no options are specified, only the ok and critical states are swapped. If at least one status change option is specified, only the specified states are mapped.

Sample command definitions to check that an SMTP server is not listening, and to verify that a user can’t log into a POP3 server are as follows:

  define command 
    command_name  check_nosmtp 
    command_line  $USER1$/negate $USER1$/check_smtp 
                  -H $HOSTADDRESS$ 
  define command 
    command_name  check_pop3loginfailure 
    command_line  $USER1$/negate -o critical -w ok -c critical 
                  $USER1$/check_pop -H $HOSTADDRESS$ -E 
                  -s "USER $ARG1$\r\nPASS $ARG2$\r\n" -d 5  
                  -e "ogged in" 

The first example does not use state mapping, and the default ok for critical state replacement is done. The second example maps the states so that if a server is not listening or if the user is actually able to log in, it is considered a critical status for the service.

Related Articles

How to add swap space on Ubuntu 21.04 Operating System

How to add swap space on Ubuntu 21.04 Operating System

The swap space is a unique space on the disk that is used by the system when Physical RAM is full. When a Linux machine runout the RAM it use swap space to move inactive pages from RAM. Swap space can be created into Linux system in two ways, one we can create a...

read more

Lorem ipsum dolor sit amet consectetur


Submit a Comment

Your email address will not be published. Required fields are marked *

15 + 1 =