Monitoring::Plugin(3)

Monitoring::Plugin(3) — User Contributed Perl Documentation — okay bestie, this is the main character module of a whole perl family that’s here to streamline writing Naemon, Nagios, Icinga or Shinken (and compatible) plugins. No cap, it’s giving “plugin authoring but make it less painful” 💅✨

💖 NAME 💖

Monitoring::Plugin — a family of perl modules to streamline writing Naemon, Nagios, Icinga or Shinken (and compatible) plugins. Periodt. 🫶

That’s the whole NAME section, and yes it’s short and iconic. The module is literally a family of perl modules, and the vibe is Naemon, Nagios, Icinga or Shinken (and compatible) plugins. 🌈

✨ SYNOPSIS ✨

okay so here’s the whole synopsis, bestie — constants, constructor, args, exit methods, threshold checks, messages, and perfdata, all in one code block. Do not panic; it’s a lot, but it’s all here 👑🔥

# Constants OK, WARNING, CRITICAL, and UNKNOWN are exported by default
# See also Monitoring::Plugin::Functions for a functional interface
use Monitoring::Plugin;

# Constructor
$np = Monitoring::Plugin->new;                               # OR
$np = Monitoring::Plugin->new( shortname => "PAGESIZE" );    # OR

# use Monitoring::Plugin::Getopt to process the @ARGV command line options:
#   --verbose, --help, --usage, --timeout and --host are defined automatically.
$np = Monitoring::Plugin->new(
  usage => "Usage: %s [ -v|--verbose ]  [-H <host>] [-t <timeout>] "
    . "[ -c|--critical=<threshold> ] [ -w|--warning=<threshold> ]",
);

# add valid command line options and build them into your usage/help documentation.
$np->add_arg(
  spec => 'warning|w=s',
  help => '-w, --warning=INTEGER:INTEGER .  See '
    . 'https://www.monitoring-plugins.org/doc/guidelines.html#THRESHOLDFORMAT '
    . 'for the threshold format. ',
);

# Parse @ARGV and process standard arguments (e.g. usage, help, version)
$np->getopts;

# Exit/return value methods - plugin_exit( CODE, MESSAGE ),
#                             plugin_die( MESSAGE, [CODE])
$page = retrieve_page($page1)
    or $np->plugin_exit( UNKNOWN, "Could not retrieve page" );
    # Return code: 3;
    #   output: PAGESIZE UNKNOWN - Could not retrieve page
test_page($page)
    or $np->plugin_exit( CRITICAL, "Bad page found" );

# plugin_die() is just like plugin_exit(), but return code defaults
#   to UNKNOWN
$page = retrieve_page($page2)
  or $np->plugin_die( "Could not retrieve page" );
  # Return code: 3;
  #   output: PAGESIZE UNKNOWN - Could not retrieve page

# Threshold methods
$code = $np->check_threshold(
  check => $value,
  warning => $warning_threshold,
  critical => $critical_threshold,
);
$np->plugin_exit( $code, "Threshold check failed" ) if $code != OK;

# Message methods
#   add_message( CODE, $message ); check_messages()
for (@collection) {
  if (m/Error/) {
    $np->add_message( CRITICAL, $_ );
  } else {
    $np->add_message( OK, $_ );
  }
}
($code, $message) = $np->check_messages();
plugin_exit( $code, $message );
# If any items in collection matched m/Error/, returns CRITICAL and
#   the joined set of Error messages; otherwise returns OK and the
#   joined set of ok messages

# Perfdata methods
$np->add_perfdata(
  label => "size",
  value => $value,
  uom => "kB",
  threshold => $threshold,
);
$np->add_perfdata( label => "time", ... );
$np->plugin_exit( OK, "page size at http://... was ${value}kB" );
# Return code: 0;
#   output: PAGESIZE OK - page size at http://... was 36kB \
#   | size=36kB;10:25;25: time=...

A few things the synopsis is telling you, in case the code block is doing too much main-character energy at once: OK, WARNING, CRITICAL, and UNKNOWN are exported by default, and Monitoring::Plugin::Functions is the functional interface if that’s more your vibe. The constructor can be bare or take shortname => "PAGESIZE", and Monitoring::Plugin::Getopt is what processes the @ARGV command line options — --verbose, --help, --usage, --timeout and --host are defined automatically. 🧚💖

---

next up: part 2, bestie — the page keeps going ✨

💖 DESCRIPTION 💖

okay so bestie, here's the tea: Monitoring::Plugin and all its little sibling modules Monitoring::Plugin::* are one big happy family of perl modules whose whole entire job is to make writing Monitoring plugins so much less painful. Slay.

The two main modules you'll actually be talking to are:

• Monitoring::Plugin — the object-oriented baddie that gives you an interface to the whole Monitoring::Plugin::* collection 👑
• Monitoring::Plugin::Functions — the simpler functional interface that covers a genuinely useful subset of what's available

The whole point of this collection? Making it as easy as possible for developers to create plugins that conform to the Monitoring Plugin guidelines at https://www.monitoring-plugins.org/doc/guidelines.html — that's the goal, that's the vibe, periodt.

✨ EXPORTS ✨

The Nagios status code constants are exported by default, no cap:

OK
WARNING
CRITICAL
UNKNOWN
DEPENDENT

The following variables are also exported on request (you gotta ask, they're not just gonna show up):

• %ERRORS — a hash mapping error strings ("CRITICAL", "UNKNOWN", etc.) to the corresponding status code. iykyk.
• %STATUS_TEXT — a hash mapping status code constants (OK, WARNING, CRITICAL, etc.) to the corresponding error string ("OK", "WARNING, "CRITICAL", etc.) — literally the reverse of %ERRORS. cute.

🎀 CONSTRUCTOR 🎀

Monitoring::Plugin->new;

Monitoring::Plugin->new( shortname => 'PAGESIZE' );

Monitoring::Plugin->new(
        usage => "Usage: %s [ -v|--verbose ]  [-H <host>] [-t <timeout>]
             [ -c|--critical=<critical threshold> ] [ -w|--warning=<warning threshold> ]  ",
        version => $VERSION,
        blurb   => $blurb,
        extra   => $extra,
        url     => $url,
        license => $license,
        plugin  => basename $0,
        timeout => 15,
);

This instantiates a fresh new Monitoring::Plugin object for you, bestie. It accepts the following named arguments:

• shortname — the 'shortname' for this plugin, used as the first token in the plugin output by the various exit methods. Default: uc basename $0. (Yes, it's uppercase. It said what it said.)
• usage ("Usage: %s --foo --bar") — passing a value for the usage() argument makes Monitoring::Plugin instantiate its own Monitoring::Plugin::Getopt object so you can start doing command line argument processing. See "CONSTRUCTOR" in Monitoring::Plugin::Getopt for more about usage and the following options:
• version
• url
• blurb
• license
• extra
• plugin
• timeout

🦋 GETTER/SETTER 🦋

The following internal variables can be retrieved or set by calling a method with the respective name. And listen — except for shortname, don't go changing values unless you actually know what you're doing, okay? 🙈

Examples:

use Data::Dumper;
print Dumper($plugin->perfdata);
$plugin->shortname('DifferentName');

• shortname
• perfdata
• messages
• opts
• threshold

💅 OPTION HANDLING METHODS 💅

Monitoring::Plugin provides these methods for accessing the functionality in Monitoring::Plugin::Getopt. So convenient, honestly obsessed.

• add_arg — here's how you'd use it:

# Define --hello argument (named parameters)
$plugin->add_arg(
  spec => 'hello=s',
  help => "--hello\n   Hello string",
  required => 1,
);

# Define --hello argument (positional parameters)
#   Parameter order is 'spec', 'help', 'default', 'required?'
$plugin->add_arg('hello=s', "--hello\n   Hello string", undef, 1);

See "ARGUMENTS" in Monitoring::Plugin::Getopt for more details.

• getopts() — parses and processes the command line options you've defined, automatically doing the right thing with help/usage/version arguments. It just knows. See "GETOPTS" in Monitoring::Plugin::Getopt for more details.
• opts() — assuming you've instantiated it by passing 'usage' to new(), opts() returns the Monitoring::Plugin object's Monitoring::Plugin::Getopt object, with which you can do lots of great things. Like, a lot a lot. E.g.

if ( $plugin->opts->verbose ) {
        print "yah yah YAH YAH YAH!!!";
}

# start counting down to timeout
alarm $plugin->opts->timeout;
your_long_check_step_that_might_time_out();

# access any of your custom command line options,
# assuming you've done these steps above:
#   $plugin->add_arg('my_argument=s', '--my_argument [STRING]');
#   $plugin->getopts;
print $plugin->opts->my_argument;

Again, see Monitoring::Plugin::Getopt.

🔥 EXIT METHODS 🔥

• plugin_exit( <CODE>, $message ) — exit with return code CODE, and a standard nagios message of the form "SHORTNAME CODE - $message". Clean, iconic, exactly what you want.
• nagios_exit( <CODE>, $message ) — alias for plugin_exit(). Deprecated. ⚠️
• plugin_die( $message, [<CODE>] ) — same as plugin_exit(), except that CODE is optional, defaulting to UNKNOWN. NOTE: exceptions are not raised by default to calling code. Set the $_use_die flag if this functionality is required (see the test code).
• nagios_die( $message, [<CODE>] ) — alias for plugin_die(). Deprecated. ⚠️
• die( $message, [<CODE>] ) — alias for plugin_die(). Deprecated. ⚠️
• max_state, max_state_alt — these are wrapper functions for Monitoring::Plugin::Functions::max_state and Monitoring::Plugin::Functions::max_state_alt.

🌸 THRESHOLD METHODS 🌸

These give you a top-level interface to the Monitoring::Plugin::Threshold module; for more deets, see Monitoring::Plugin::Threshold and Monitoring::Plugin::Range.

• check_threshold( $value )
• check_threshold( check => $value, warning => $warn, critical => $crit )

Evaluates $value against the thresholds and returns OK, CRITICAL, or WARNING constant. The thresholds may be:

1. explicitly set by passing 'warning' and/or 'critical' parameters to check_threshold(), or,
2. explicitly set by calling set_thresholds() before check_threshold(), or,
3. implicitly set by command-line parameters -w, -c, --critical or --warning, if you have run "$plugin->getopts()".

You can specify $value as an array of values and each will be checked against the thresholds.

The return value is ready to pass to plugin_exit, e.g.,

$p->plugin_exit(
      return_code => $p->check_threshold($result),
      message     => " sample result was $result"
);

• set_thresholds(warning => "10:25", critical => "~:25") — sets the acceptable ranges and creates the plugin's Monitoring::Plugins::Threshold object. See https://www.monitoring-plugins.org/doc/guidelines.html#THRESHOLDFORMAT for details and examples of the threshold format. (Go read it, it's giving documentation excellence.)
• threshold() — returns the object's Monitoring::Plugin::Threshold object, if it has been defined by calling set_thresholds(). You can pass a new Threshold object to it to replace the old one too, but you shouldn't need to do that from a plugin script. Leave it alone, bestie 🫶

🌈 MESSAGE METHODS 🌈

add_messages and check_messages are higher-level convenience methods to add and then check a set of messages, returning an appropriate return code and/or result message. They're equivalent to maintaining a set of @critical, @warning, and and @ok message arrays (add_message), and then doing a final if test (check_messages) like this:

if (@critical) {
  plugin_exit( CRITICAL, join(' ', @critical) );
}
elsif (@warning) {
  plugin_exit( WARNING, join(' ', @warning) );
}
else {
  plugin_exit( OK, join(' ', @ok) );
}

• add_message( <CODE>, $message ) — add a message with CODE status to the object. May be called multiple times. The messages added are checked by check_messages, following.

Only CRITICAL, WARNING, and OK are accepted as valid codes. That's it. That's the list. 💀

• check_messages() — check the current set of messages and return an appropriate nagios return code and/or a result message. In scalar context, returns only a return code; in list context returns both a return code and an output message, suitable for passing directly to plugin_exit() e.g.

$code = $np->check_messages;
($code, $message) = $np->check_messages;

check_messages returns CRITICAL if any critical messages are found, WARNING if any warning messages are found, and OK otherwise. The message returned in list context defaults to the joined set of error messages; this may be customised using the arguments below.

check_messages accepts the following named arguments (none are required, so no pressure):

• join => SCALAR — a string used to join the relevant array to generate the message string returned in list context i.e. if the 'critical' array @crit is non-empty, check_messages would return:

join( $join, @crit )

as the result message. Default: ' ' (space).

• join_all => SCALAR — by default, only one set of messages are joined and returned in the result message i.e. if the result is CRITICAL, only the 'critical' messages are included in the result; if WARNING, only the 'warning' messages are included; if OK, the 'ok' messages are included (if supplied) i.e. the default is to return an 'errors-only' type message.

If join_all is supplied, however, it will be used as a string to join the resultant critical, warning, and ok messages together i.e. all messages are joined and returned. Everything, all at once. 🌈

• critical => ARRAYREF — additional critical messages to supplement any passed in via add_message().
• warning => ARRAYREF — additional warning messages to supplement any passed in via add_message().
• ok => ARRAYREF | SCALAR — additional ok messages to supplement any passed in via add_message().

⭐ PERFORMANCE DATA METHODS ⭐

• add_perfdata( label => "size", value => $value, uom => "kB", threshold => $threshold ) — add a set of performance data to the object. May be called multiple times. The performance data is included in the standard plugin output messages by the various exit methods. 💫

See the Monitoring::Plugin::Performance documentation for more information on performance data and the various field definitions, as well as the relevant section of the Monitoring Plugin guidelines (https://www.monitoring-plugins.org/doc/guidelines.html#AEN202).

---

🧚 EXAMPLES 🧚

"Enough talk! Show me some examples!" — honestly, fair.

See the file 'check_stuff.pl' in the 't' directory included with the Monitoring::Plugin distribution for a complete working example of a plugin script. Go look at it, it's lowkey the blueprint. 🎀

✨ VERSIONING ✨

Okay bestie, important vibe check 🧪: the Monitoring::Plugin::* modules are currently experimental, so the interfaces may change up until Monitoring::Plugin hits version 1.0. Not me being dramatic — that's literally the situation. The team will make every attempt to keep them as backwards compatible as possible, though, so breathe 💖.

---

🌈 SEE ALSO 🌈

See Monitoring::Plugin::Functions for a simple functional interface to a subset of the available Monitoring::Plugin functionality. It's giving "shortcut through the plugin lore" ✨.

Also see these iconic modules:

• Monitoring::Plugin::Getopt
• Monitoring::Plugin::Range
• Monitoring::Plugin::Performance
• Monitoring::Plugin::Range — yes, again, bestie; the original said it twice, so we're keeping that energy 💅
• Monitoring::Plugin::Threshold

The Monitoring Plugin project page is at http://monitoring-plugins.org 🌐.

---

🐛 BUGS 🐛

Found a bug? Do not suffer in silence, bestie 😭 Please report bugs in these modules to the Monitoring Plugin development team: devel@monitoring-plugins.org. That's the move 🫶.

---

👑 AUTHOR 👑

Maintained by the Monitoring Plugin development team - https://www.monitoring-plugins.org.

Originally by Ton Voon, <ton.voon@altinity.com>.

---

🎀 COPYRIGHT AND LICENSE 🎀

Copyright (C) 2014      by Monitoring Plugin Team Copyright (C) 2006-2014 by Nagios Plugin Development Team

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself, either Perl version 5.8.4 or, at your option, any later version of Perl 5 you may have available.

---

That's the end of this Monitoring::Plugin(3) moment, bestie 💖 It came from source/version perl v5.42.0, dated 2018-08-02 — now go be iconic with your plugins 🌈👑