[Nagiosplug-devel] Nagios::Plugin api
Gavin Carr
gavin at openfusion.com.au
Fri Sep 1 23:20:44 CEST 2006
On Thu, Aug 31, 2006 at 10:29:56AM +0100, Ton Voon wrote:
> On 30 Aug 2006, at 21:04, Vonnahme, Nathan wrote:
>
> >I like that, it is more intuitive. Maybe it should default to UNKNOWN
> >though-- you should explicitly throw CRITICAL or WARNING if it's an
> >expected problem (the thing you're checking is down/excessive), and
> >just
> >plain die() (which would return UNKNOWN) if it's something that keeps
> >you from checking, like if a file your check script needs isn't there.
>
> Agreed. UNKNOWN is a better default.
Ok - default to UNKNOWN.
> >What about even overloading the die and end handlers like this (I may
> >not have it quite right... and you'd have to do it in the check
> >script,
> >not the module) ?
>
> I like the idea of overloading die - keeps it v simple - but only if
> it doesn't need to be specified at the plugin script (eg, can we get
> it automatically just by use Nagios::Plugin?).
>
> Also, does that mean the object will return the data? Or all the
> setup stuff is class data?
Overloading die is nice, but it's reasonably unexpected from a user
point of view. I wonder if we should make Nagios::Plugin work something
like File::Spec does: by default, nothing is exported into the user's
environment, and everything is called via class or object methods e.g.
Nagios::Plugin->die( 'bad result' );
$np->exit( 'everything ok' );
Then you have an alternative functional interface if you want to use
exported/exportable functions instead (including overriding die, for
instance), like Nagios::Plugin::Functions (cf. File::Spec::Functions):
use Nagios::Plugin::Functions;
die( $failure, CRITICAL );
Cheers,
Gavin
More information about the Devel
mailing list