[Nagiosplug-devel] Nagios::Plugin suggestions
Ton Voon
ton.voon at altinity.com
Fri Feb 9 10:19:47 CET 2007
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
More information about the Devel
mailing list