[Nagiosplug-devel] Nagios::Plugin suggestions

[Gavin Carr]

Hi Ton,

On Thu, Feb 08, 2007 at 03:30:47PM +0000, Ton Voon wrote:
> ADD_ARG METHOD
> 
> For $np->add_arg(), one thing I've noticed myself repeating is the  
> help output. The syntax output is effectively already defined in the  
> spec. Plus, to get the output lined up correctly with the default  
> args in --help, you need to add a linefeed and extra spaces. What about:
> 
> $np->add_arg(
>    spec => "warning|w=s",
>    type => "RANGE",
>    help => "Warning if time is outside RANGE",
>    );
> 
> The idea is that the spec line will print "-w, --warning=RANGE", with  
> a new line and the appropriate number of spaces before printing $help.
> 
> This should also make it a bit easier to internationalisation as the  
> help line is the only portion that needs translating.

That's a good suggestion; in fact, I wonder whether it's worth doing 
even if 'type' isn't specified e.g. spec => 'timeout|t=i' could still
automagically prepend '-t, --timeout=INTEGER\n  ' in much the same way,
and 'query|q=s' could become '-q, --query=STRING\n  '.

We can handle backward compatibility simply be checking whether the 
help begins with -X or --LONG, and not munging it if so. That work?

Type would then be purely optional, but replaces the default 
INTEGER/STRING label if specified?

Next question: can types be arbitrary, or only pre-defined? If they're
primarily labels, perhaps they can be arbitrary e.g. query, type => 'SQL';
pattern, type => 'REGEX'; username, type => 'USERNAME'. If we're adding
behaviors to them, though (RANGE, THRESHOLD, etc.), then they should 
perhaps be restricted. Hmmm.


> I'm also thinking ahead to new threshold formats, so that if type is  
> THRESHOLD, some other processing can happen (validation of threshold  
> values?).
> 
> We can be backwards compatible so that the old behaviour happens if  
> type is not specified (though mark this as deprecated behaviour).
> 
> Also, I'd like to add default => "5" to the add_arg, if you wish to  
> set a default value.

Already there. :-) Although this may well be a documentation bug. The
Nagios::Plugin::Getopt docs should be reasonably comprehensive, but 
the Nagios::Plugin ones may not include stuff they should. There's also
a 'required => 1' option for mandatory args.

> HELP OUTPUT
> 
> Currently this is sent to stderr. This should be stdout with respects  
> to the C plugins, though I can't find it documented in the dev  
> guidelines. Agreed?

Happy either way.

> MAX_STATE
> 
> I've added a max_state function into N::P::Functions that mimics the  
> C version, but not sure how to add into the N::P object. It seems  
> that the object itself doesn't have the idea of a current state -  
> would that be a good idea or not? If the object does know state, then  
> $np->max_state( $new_state ) could do a $self->state( new_state 
> ( $self->state || "", $new_state) ) ?

No, N::P is stateless at the moment. I take it you're thinking of being
able to do a few check_thresholds, for instance, and then dying if the
max_state so far is critical or warning or something?

You might also want to look at the add_message / check_message interface 
too, which is the closest thing to statefulness right now.

Cheers,
Gavin 


-- 
Gavin Carr
- http://www.openfusion.com.au - Linux, Perl, and Web Consulting
- http://www.xool.com.au - Xool, Australian property search engine
* Fashion is a variable, but style is a constant - Programming Perl