Two threshold types in one

[reincarne]

Hi, sorry for the title which doesn't say much
I have a question related to thresholds. Is there a way to put in one check two types of thresholds?
For example, I want to put thresholds for minimal and maximal: Warning/Critical if the value goes down, Warning/Critical if values goes too high.

[jwelch]

Short answer: It depends.

There is a format for ranges, but it depends on whether or not the specific check script you want to use
supports that format.

See: https://nagios-plugins.org/doc/guidelin ... HOLDFORMAT

Check the help text for plugin you want to use:

(note the usage of 'range' in the warning and critical threhold specifiers and the first example using the ':'.)

Code: Select all

/usr/local/nagios/libexec/check_procs -h
check_procs v2.0.3 (nagios-plugins 2.0.3)
Copyright (c) 1999 Ethan Galstad <[email protected]>
Copyright (c) 2000-2014 Nagios Plugin Development Team
        <[email protected]>

Checks all processes and generates WARNING or CRITICAL states if the specified
metric is outside the required threshold ranges. The metric defaults to number
of processes.  Search filters can be applied to limit the processes to check.


Usage:
check_procs -w <range> -c <range> [-m metric] [-s state] [-p ppid]
 [-u user] [-r rss] [-z vsz] [-P %cpu] [-a argument-array]
 [-C command] [-k] [-t timeout] [-v]

Options:
 -h, --help
    Print detailed help screen
 -V, --version
    Print version information
 --extra-opts=[section][@file]
    Read options from an ini file. See
    https://www.nagios-plugins.org/doc/extra-opts.html
    for usage and examples.
 -w, --warning=RANGE
   Generate warning state if metric is outside this range
 -c, --critical=RANGE
   Generate critical state if metric is outside this range
 -m, --metric=TYPE
  Check thresholds against metric. Valid types:
  PROCS   - number of processes (default)
  VSZ     - virtual memory size
  RSS     - resident set memory size
  CPU     - percentage CPU
  ELAPSED - time elapsed in seconds
 -t, --timeout=INTEGER
    Seconds before plugin times out (default: 10)
 -v, --verbose
    Extra information. Up to 3 verbosity levels
 -T, --traditional
   Filter own process the traditional way by PID instead of /proc/pid/exe

Filters:
 -s, --state=STATUSFLAGS
   Only scan for processes that have, in the output of `ps`, one or
   more of the status flags you specify (for example R, Z, S, RS,
   RSZDT, plus others based on the output of your 'ps' command).
 -p, --ppid=PPID
   Only scan for children of the parent process ID indicated.
 -z, --vsz=VSZ
   Only scan for processes with VSZ higher than indicated.
 -r, --rss=RSS
   Only scan for processes with RSS higher than indicated.
 -P, --pcpu=PCPU
   Only scan for processes with PCPU higher than indicated.
 -u, --user=USER
   Only scan for processes with user name or ID indicated.
 -a, --argument-array=STRING
   Only scan for processes with args that contain STRING.
 --ereg-argument-array=STRING
   Only scan for processes with args that contain the regex STRING.
 -C, --command=COMMAND
   Only scan for exact matches of COMMAND (without path).
 -k, --no-kthreads
   Only scan for non kernel threads (works on Linux only).

RANGEs are specified 'min:max' or 'min:' or ':max' (or 'max'). If
specified 'max:min', a warning status will be generated if the
count is inside the specified range

This plugin checks the number of currently running processes and
generates WARNING or CRITICAL states if the process count is outside
the specified threshold ranges. The process count can be filtered by
process owner, parent process PID, current state (e.g., 'Z'), or may
be the total number of running processes

Examples:
 check_procs -w 2:2 -c 2:1024 -C portsentry
  Warning if not two processes with command name portsentry.
  Critical if < 2 or > 1024 processes

 check_procs -w 10 -a '/usr/local/bin/perl' -u root
  Warning alert if > 10 processes with command arguments containing
  '/usr/local/bin/perl' and owned by root

 check_procs -w 50000 -c 100000 --metric=VSZ
  Alert if VSZ of any processes over 50K or 100K

 check_procs -w 10 -c 20 --metric=CPU
  Alert if CPU of any processes over 10%% or 20%%

Send email to [email protected] if you have questions regarding use
of this software. To submit patches or suggest improvements, send email to
[email protected]

Then run it from the command line to verify that it works the way you want:

Code: Select all

 ./check_procs -w 1:10 -c 0:100 -C /usr/sbin/httpd
PROCS WARNING: 0 processes with command name '/usr/sbin/httpd' | procs=0;1:10;0:100;0;
 ./check_procs -w 1:10 -c 0:100 -C httpd
PROCS WARNING: 21 processes with command name 'httpd' | procs=21;1:10;0:100;0;
 ./check_procs -w 1:30 -c 0:100 -C httpd
PROCS OK: 21 processes with command name 'httpd' | procs=21;1:30;0:100;0;
 ./check_procs -w 25:30 -c 0:100 -C httpd
PROCS WARNING: 21 processes with command name 'httpd' | procs=21;25:30;0:100;0;

[lmiltchev]

reincarne, let us know if jwelch answered your question.

[reincarne]

Thanks, I will try it first.

[lmiltchev]

OK, keep us posted.

[jwelch]

Before I stumbled onto the 'official' method of designating ranges, I used
-w -c for lower limits and -W -C for upper limits in my own scripts. Your
script (depending on it's source) could do something similar or use another
method...only way to be sure is to look at the code.

[tmcdonald]

reincarne, what specific plugin are you using? Can you link to it?

[reincarne]

reincarne, what specific plugin are you using? Can you link to it?

The question was general.
I understood that it depends on the plugin - if plugin support Maximal and Minimal thresholds then it is possible, if not then Nagios doesn't know to use the negative logic which is pretty disappointing.

[tmcdonald]

It's not that Nagios doesn't know how to use the logic, it's that the logic has not been presented to Nagios. There are plenty of situations where a negative reading could be perfectly valid (temperatures being the first to come to mind) and if Nagios treated all negative values the same way then some plugins would fail to work properly. This is why we have the plugins themselves interpret readings as they see fit, then report this info to Nagios for further processing.

[reincarne]

It's not that Nagios doesn't know how to use the logic, it's that the logic has not been presented to Nagios. There are plenty of situations where a negative reading could be perfectly valid (temperatures being the first to come to mind) and if Nagios treated all negative values the same way then some plugins would fail to work properly. This is why we have the plugins themselves interpret readings as they see fit, then report this info to Nagios for further processing.

Thanks mate