[Nagiosplug-devel] Nagios::Plugin thresholds

[Gavin Carr]

Ton Voon scribed in a previous thread:
> >> Gavin Carr pontificated thusly:
> >>
> >>- With thresholds, returning an object from set_thresholds seems
> >>  strange to me:
> >>    
> >>    $threshold = $p->set_thresholds( warning => "10:25", critical
> >>=> "25:" );
> >>    
> >>  I think that if you're going to return an object, you should just
> >>  use Nagios::Plugin::Threshold directly:
> >>  
> >>    $threshold = Nagios::Plugin::Threshold->new( warning =>
> >>"10:25", critical => "25:" );
> >>
> >>  Or if you want to use composition, you shouldn't return the object
> >>  at all - just
> >>
> >>    $p->set_thresholds( warning => "10:25", critical => "25:" );
> >>
> >>  or perhaps:
> >>
> >>     $p = Nagios::Plugin->new( warning => "10:25", critical =>
> >>"25:" );
> >>
> >>  (In practice, I guess thresholds are most often going to come in as
> >>   arguments anyway, so we would presumably most often want to get
> >>them
> >>   via Nagios::Plugin::Getopt arguments somehow ...)
> >>  
> >>  If you're going with composition, then you'd call the threshold
> >>  get_status implicitly rather than explicitly e.g. instead of:
> >>
> >>    $p->die( return_code => $threshold->get_status($value), message
> >>=> $msg )
> >>
> >>  perhaps something like:
> >>
> >>    $p->exit_check_threshold(check => $value);
> >>    $p->exit_check_threshold($value);
> 
> Hmmm. I can't remember why I did it like this. There could be
> multiple thresholds per plugin (check_disk can check absolute disk
> free, absolute disk used, percent disk used, percent disk free,
> absolute inodes free, etc), so there needs to be a list of
> thresholds. Yes, they are likely to come via N::P::Getopt arguments,
> but I guess they need to be pulled out at certain times too (you've
> put 'check => $value' above - how do we reference 'check'?).
> 
> In summary, I'm not sure what my position on this is yet. :)
> 
> $p->exit_check_threshold( check => $value ) is a good idea for a
> shortcut method to $p->exit( ... ).

For simplicity, let's start with single thresholds. If we want to
handle multiple thresholds cleverly later (as opposed to just iterating
over them), I guess we layer that on top?

My main point above was just that we should either expose 
Nagios::Plugin::Thresholds fully and let them be used directly, or
hide them away entirely - it seems to me the current api is doing 
something in between.

How about something like this:

  $plugin->check_threshold(
    check => $value, message => "page size at http://... was ${value}kB",
    warning => $warning, critical => $critical,
  );

which creates your N::P::Threshold object behind the scenes, sets the
thresholds using $warning and $critical, calls N::P::Threshold->get_status, 
and exits iff the result is a WARNING or a CRITICAL. 

You might also have:

  $plugin->check_threshold_exit( <same_args> );

which always exits i.e. it's a convenience for:

  $self->check_threshold( %args );
  $self->nagios_exit( OK, %args{message} );


Good/bad/ugly?

Cheers,
Gavin