| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
when warning and critical is passed in, so that order of execution between $mp->check_threshold and $mp->add_perfdata doesn't matter
|
|
|
|
The Config::Tiny parent class for Monitoring::Plugin::Config does not
necessarily raise an exception in $@/$EVAL_ERROR on a failed call to its
->read() method. Indeed, it does not in most cases, at least in the most
recent Config::Tiny.
If a file does not exist or for whatever other reason cannot actually be
read--such as permissions problems--Monitoring::Plugin ends up reporting
a "Missing config section" to the caller, which is misleading.
This information is available from the ->errstr() method of the base
class, however, and an inspection of the code for the ->read() method in
the parent class suggests the correct approach is to look for a return
of `undef` from the ->read() method, and use the return value of
->errstr() as the reported error for ->_die(). This commit adds such a
check.
To reproduce, given the following plugin `mptest`:
use strict;
use warnings;
use Monitoring::Plugin qw(%ERRORS);
my $mp = Monitoring::Plugin->new(
usage => '',
);
$mp->getopts;
$mp->plugin_exit($ERRORS{OK}, 'Done!');
Running it without options of course works, like so:
$ perl mptest
MPTEST OK - Done!
However, prior to this patch, if we specify --extra-opts with a
nonexistent filename, we get a misleading error:
$ perl mptest --extra-opts=@/nonexistent
Invalid section 'mptest' in config file '/nonexistent'
With this patch included, the error is more accurate and helpful:
$ perl mptest --extra-opts=@/nonexistent
Failed to open file '/nonexistent' for reading: No such file or directory
|
|
From a maintainer, Sven Nierlein:
> I'd say we can remove the "experimental" tag there. It had been there
> for years now and i see no reason why we would change them.
Partly resolves #14.
|
|
Context with the lhs of the == operator forces this into scalar context
anyway, making this call redundant.
|
|
Since Params::Validate::validate() doesn't seem to actually mess with
this specification, may as well pass a reference rather than bother
copying the whole thing.
|
|
Operator precedence allows leaving these out.
|
|
Define the expected order of parameters by key in an array, and then
apply hash slices to validate and assign the arguments including their
required flags in one swoop, again hinging on the parameter definitions
established in c1046ba.
|
|
Use the parameter label definitions from commit c1046ba to simplify the
block of code that checks whether the first argument passed to arg() is
one of the known param keys, rather than using a regular expression with
alternating expression.
This is more compact, may be marginally faster, and will make adding new
parameters to this method more straightforward in future, avoiding the
situation corrected in commit 4aa2aee.
|
|
This shift and its comment makes what the values of the hashref passed
to the validate() methods mean clearer, and also allows the use of the
keys as a means of determining whether arg() was passed its definition
in the array or hash format in a separate commit.
|
|
If the `label` key is given as a named argument for argument
specification, if it turns out to be the first element returned in the
argument list subject to hash randomization, then this test for named
arguments fails due to the omission of the label from this alternating
group in the pattern.
When this happens, the code for an unnamed list of items was run
instead, leading to a very confusing area happening randomly:
8 parameters were passed to Monitoring::Plugin::Getopt::arg but 2 - 5 were expected
at PERL/lib/perl5/Monitoring/Plugin/Getopt.pm line 397.
Monitoring::Plugin::Getopt::arg(undef, "label", "HOSTNAME", "required", 1, "help", "Hostname of device to check", "spec", ...) called at PERL/lib/perl5/Monitoring/Plugin.pm line 161
Monitoring::Plugin::add_arg(Monitoring::Plugin=HASH(0x1f90fd8), "label", "HOSTNAME", "required", 1, "help", "Hostname of device to check", "spec", ...) called at libexec/check_example line 144
If you specified all five keys for your argument, then this happens
(roughly) one-fifth of the time.
|
|
Getopt::Long supports negatable boolean options by appending an '!' to the
option specification, so this allows to use this functionality with
Monitoring::Plugin::Getopt as well.
|
|
|
|
Fix plugin-name processing in ALRM handler.
|
|
Signed-off-by: Sven Nierlein <sven@nierlein.de>
|
|
Allow hypen or underscore in plugin name.
|
|
Wrong case in ALRM regex.
|
|
\R was introduced in 5.10 too
|
|
|
|
Added tests.
|
|
Pass `TEXT OUTPUT\nLONGTEXT1\nLONGTEXT2` to as the second parameter to `plugin_exit()` to add LONGOUTPUT lines. If the parameter is has a leading newline (i.e. `\nLONGTEXT1\nLONGTEXT2`), skip emitting the hyphen (dash).
|
|
output empty performance data value as value "U" to "indicate that the actual value couldn't be determined" (defined in https://nagios-plugins.org/doc/guidelines.html#AEN200) and do valid output
|
|
Signed-off-by: Sven Nierlein <sven@nierlein.de>
Original-Author: Christoph Biedl <debian.axhn@manchmal.in-ulm.de>
|
|
Signed-off-by: Sven Nierlein <sven@nierlein.de>
|
|
Signed-off-by: Sven Nierlein <sven@nierlein.de>
|
|
GetOpt::Long optional arguments using a colon instead of an equal sign
|
|
Signed-off-by: Sven Nierlein <sven@nierlein.de>
|
|
Signed-off-by: Sven Nierlein <sven@nierlein.de>
|
|
its not true that the options are available via the main
Monitoring::Plugin object. Instead you have to fetch them
from the opts object.
Signed-off-by: Sven Nierlein <sven@nierlein.de>
|
|
|
|
Instead of writing `foo|f=s` you can also write `foo|f:s` for a GetOpt::Long
option spec [1], thus making the argument optional.
The current implementation of `_spec_to_help` will wrongly render this as two
long options:
--dirport, --d:9030
directory port
instead of a short and a long one:
-d, --dirport=INTEGER
directory port
This commit fixes the the parsing of the spec, detection of the type and adds
tests for a few common cases this could be used in.
[1] http://perldoc.perl.org/Getopt/Long.html#Summary-of-Option-Specifications
|
|
Signed-off-by: Sven Nierlein <sven@nierlein.de>
|
|
since the complete monitoring team has been renamed, we
also rename this module.
Signed-off-by: Sven Nierlein <sven@nierlein.de>
|
|
Now allow the section names to contain all characters except "@"
|
|
When a default file is used but no section is found (ex. below using
"bad_section"), the plugin dies with:
Invalid section 'bad_section' in config file ''
This patch add a function to Nagios::Plugin::Config that returns the last
used file, and use it to return a file name when we have none.
|
|
|
|
|
|
|
|
|
|
|
|
A "=back" command was missing. (Fixed by Ryan Niebur for Debian,
forwarded by Ansgar Burchardt - RT56683)
|
|
|
|
|
|
|
|
This patch makes shortname use the defined plugin's name if set,
otherwise the normal method should prevail. To do so I had to
generate shortname during np initialization instead of at use time.
|
|
nagios_die() accepts many ways of specifying arguments. One of them is
passing the message only, in which case the last argument added by
Plugins.pm is on the 2nd position instead of the 3rd. One visible
effect of this bug is the inability to print custom "shortname" with
nagios_die when the exit code is not specified.
|
|
|
|
|
|
|
