Exploding check commands batman ...

[Andreas Ericsson]

Gavin Carr wrote:
> On Fri, Jul 01, 2005 at 09:28:45PM +0200, Andreas Ericsson wrote:
> 
>>I was thinking along the lines of this;
>>
>>command_name  check_foo_command
>>command_line  check_foo -H $HOSTADDRESS$ -C "$ARG1$" -p "$ARG2$"
>>
>>Where check_foo is a plugin written in perl that checks something via 
>>SNMP. It's reasonable to assume that most will want to give the 
>>community as an argument from the service-object, while most want to use 
>>the default port.
>>
>>Nagios will translate all 32 $ARGx$ macros even if some aren't set 
>>(which is a bit weird, but useful for this purpose) and simply remove 
>>the macro-tags since their counterparts will be NULL pointers (as 
>>opposed to null strings).
>>
>>So, the resulting command turns out to
>>
>>check_foo -H host -C bar -p ""
>>
>>which means the imaginary variable $port will be set to the null-string 
>>and thus it will be defined but will evaluate to false when being 
>>evaluated as a boolean expression, as it would have if it wasn't 
>>specified at all.
> 
> 
> That's a nice idea Andreas. So are you adding the boolean testing to the 
> current nagios plugin infrastructure?
> 

To my fork of it, actually. Perhaps it'll be the default branch some day 
(I certainly hope so). I've long since given up juggling the 30 or so 
patches I had to match the latest CVS.

> The only real negative is that you're then likely to use check commands
> with more options, and because we're using positional arguments you're
> likely to end up with lots of empty placeholders e.g.
> 
>   check_command   check_http!/foo/bar.html!!!!!404
> 
> etc.
> 
> A nasty example of this is things like check_by_ssh checks, where your 
> arguments are typically on the inner command rather than the other 
> check_by_ssh one e.g.
> 

For check_by_ssh and friends which in turn execute other plugins it's 
most likely preferrable to not use overloaded plugins, because the 
diversity is too great. For some plugins the syntax needs to be changed 
somewhat. check_http should for instance be capable of understanding
10.0.0.1/foobar as a hostaddress with a url attached which would make 
things a bit easier (as well as more obvious).

>   command_line    $USER1$/check_by_ssh -4 -H $HOSTADDRESS$ -t 20 -C '/usr/lib/nagios/plugins/check_disk -w $ARG1$ -c $ARG2$ -l'
>   command_line    $USER1$/check_by_ssh -4 -H $HOSTADDRESS$ -t 20 -C '/usr/lib/nagios/plugins/check_swap -w $ARG1$ -c $ARG2$'
> 
> I've got 10 or so of these tests defined, and now have a host that is
> listening on a non-standard ssh port. Adding a '-p "$ARG1$"' to the 
> check_by_ssh is doable, of course, but it necessitates an empty first 
> argument for all test on hosts with standard ssh ports, which is a bit
> ugly too. 
> 
> Anyone think of an elegant way to handle this?
> 

Put optional and less used arguments last in the command definition. You 
obviously wouldn't want port to be the sixth argument to generic 
check_tcp, since it's required when not using one of the symlinks.

I'm not looking to removing the need for multiple commands altogether. I 
just want to improve things a bit so users have more flexibility, that's 
all. For true overloading one would have to implement parsing in nagios 
and a more complex syntax. I'm not sure that would help very many people.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Lead Developer


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null