On 28.01.2014 14:46, Mark Haney wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 1/27/2014 4:46 PM, Michael Friedrich wrote:
On 27.01.2014 20:56, Mark Haney wrote:
No, no and no. Each CheckCommand object is unique by itself. That
does not make any sense to use one object named "check_nrpe" and
put multiple command lines into it. How would you reference it by
its name inside your service definition? That's the exact same
behavior as known from Nagios / Icinga 1.x
What Icinga 2 is telling you now is that you've "successfully"
overridden your check_nrpe command, and replaced its command with
invoking check_pgsql binary which doesn't exist nor is your
required outcome.
Okay, work with me here. If I have the check_nrpe CheckCommand object
in place (which I do), what exactly do I need to do to pass the needed
options to the check_pgsql plugin? Would I create a new Service
object for check_pgsql with the needed macros? Or would I create a
new CheckCommand object for check_pgsql?
Same as the already defined service, but with a different name, and
obviously a different value for the command macro.
services["checkload"] = {
templates = [ "generic-service" ],
notifications[ "mail" ] = {
...
}
check_command = "check_nrpe",
macros = {
command = "check_pgsql",
}
I would btw rather use different names for the remote nrpe called
command in order not to confuse it with local names.
such as in nrpe.cfg
command[nrpe_client_ping]=/usr..../check_ping ....
and then used as command macro as per reference
macros = {
command = "nrpe_client_ping",
}
But that's nitpicking and not required for solving your initial problem.
I think what's confusing me is nomenclature as much as process. With
the check_nrpe command already created, and with a $command$ macro
inside that object, I'm not sure where or how to tell the
'check_pgsql' command what parameters to use. Would it be considered
a checkcommand object or a service object?
you're executing 'check_pgsql' using the nrpe daemon. that's handled
remotely by that daemon, and icinga 2 doesn't care about its name, it
just passes that to the call of 'check_nrpe -H ... -c check_pgsql'
I'm thinking now that the check_nrpe command object is actually
calling a Service object, correct? If that's the case I would just
need to create a new service object definition for check_pgsql and add
it's required macros to the service object.
It's not exactly "calling". The service object references and existing
CheckCommand object using the attribute "check_command". In order to
inherit/pass macros from that service to the check command object, you
may user the service attribute "macros" which acts as dictionary
(key-value-tuples).
You're free to use whatever macro you prefer (except the reserved ones
throughout the docs). If you think that $command$ is not sufficient,
call it $nrpe_remote_command$ and use that as macro key in your service
then.
Am I getting close?
Sort of.
--
DI (FH) Michael Friedrich
mail: michael.friedr...@gmail.com
twitter: https://twitter.com/dnsmichi
jabber: dnsmi...@jabber.ccc.de
irc: irc.freenode.net/icinga dnsmichi
icinga open source monitoring
position: lead core developer
url: https://www.icinga.org
_______________________________________________
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
