[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