Hi!
Jan Wagner wrote:
> On Tuesday 12 May 2009, Sven Velt wrote:
> > Maybe we could add another one with "-l '$ARGV2'" add... ;-)
>
> Hmm ... I personly prefer general solutions and the one just with $ARGV1 is
> one in my eyes ... beside the documentaion shipped with nagios (upstream and
> with our package), where they use also $ARGV2, we didn't reference anything
> about such a way in our package. Why should we use different checks, if we
> can do the same with one?
>
> For example "check_command check_nt!'MEMUSE -w 80 -c 90'" works like a charm.
I think this isn't exactly the scope of this bug report but I want to
add a last statement to this.
In upstream commands.cfg many commands are defined like:
---------- snip ----------
define command{
command_name check_http
command_line $USER1$/check_http -I $HOSTADDRESS$ $ARG1$
}
---------- snip ----------
So everyone can put whatever command line arguments to check_http into
the service description like:
...
check_command check_http!-u /demo/ -w 10 -c 15 -t 20 -a user:pw -f follow
-s Linux -m 2000:5000 -M 86400
...
This may be flexible, yes, but not nice. Do you know all of the switches
to check_* which are in nagios-plugins-(basic|standard)? I don't. I told
Ethan on Nagios Konferenz 2008 that I don't like this syntax and that I
wish a more clearly way of configured check commands in the upstream
code/sample config.
As I do trainings and consulting for Nagios you can believe me that this
"flexible way of doing service definitions and check commands" is one of
the main source of problems if different people (some of them maybe not
so/100% familiar with Nagios) administer one Nagios server.
*I* prefer "check_command check_nscp!CLIENTVERSION" and "check_command
check_nscp_var_wc!USEDDISKSPACE!C:!80%!90%
Maybe we should discuss this in private?
Just IMHO. YMMV ;-)
bye
Sven
--
Leukämie -> http://de.wikipedia.org/wiki/Leuk%C3%A4mie
Heilung -> http://de.wikipedia.org/wiki/Knochenmark#Knochenmarkspende
Typisierung -> http://www.knochenmarkspende.de/html/reg_akb.php
Warum&Fragen -> s...@velt.de
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
