[Nagiosplug-devel] Nagios::Plugin suggestions

[Ton Voon]

Hi Gavin,

On 8 Feb 2007, at 22:25, Gavin Carr wrote:

> 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?

Yes, that sounds fine. I'll have a go at that.

> 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.

What about type and label? Label is completely arbitrary. Type is a  
restricted list. Label defaults to type.

We'll document only label for now, but idea is type = THRESHOLD or  
RANGE would trigger some validation. Future stuff :)


>> 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.

Sorry, should have checked. Was working only from the Nagios::Plugin  
documentation. I will make some clean ups there and add in the  
default option too.

>> 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.

OK, I'll make the change here and document in dev guidelines too.

>> 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.

OK. To be honest, I haven't got a need for the object holding state  
yet. I'll revisit when I get a more concrete example.

I'll look into the add_message interface too. Ta

Ton

http://www.altinity.com
T: +44 (0)870 787 9243
F: +44 (0)845 280 1725
Skype: tonvoon