Question 1 - Is there a difference between check_cluster and check_cluster2?
Outwardly, just the way you use them. #2 seems tidier in the way you do it.
Inwardly, I would assume #2 does it better but I've not looked into the
code of each to confirm this myself.
Question 2
Since the variable $HOSTADDRESS$ is not pass to the check_cluster command and
that hosts status are pass in the command, how did you guys configure your
stuff for the cluster service?
I was thinking about making a "ghost" host , with no notification, with
nothing, witch would have multiple cluster services. Something like...
There's probably 100 ways to skin this cat. The way we've done these
sorts of setups in v1.x (and again when we upgraded to v2) are along the
lines of...
* A host definition for each _physical_ cluster node (eg ahost01a,
ahost01b...).
* Add the usual suspects for service checks to each _physical_ (eg local
disk, cpu, memory, swap...).
* A host definition for the _virtual_ node(s) in the cluster (eg
ahost01-print, ahost01-file...).
* Add the clustered service checks to the _virtuals_, including a
check_cluster one as well (eg only the disks and service checks that
relate to that clustered service).
This would only work if you have a separate service IP for each of the
_virtuals_, and the host names in all cases would depend on how you name
your hosts. We name our cluster nodes with the node suffix for this
reason (ahost01a and ahost01b are part of a cluster, virtually, called
ahost01).
The above gets messy when you have, say, 10 services on a 2 node
cluster. You end up with 12 host defs, most of which have a single service.
A variant is to have a pseudo-virtual node for the entire cluster (eg,
physicals ahost01a and ahost01b, and virtual ahost01), and add the
clustered services to that virtual. Thus you have only 3 host
definitions. The down side is you will need to tweak the command defs as
most use $HOSTNAME$ etc for the IP, and this wouldnt necessarily be
valid if you have a unique IP for each service the cluster is providing.
I guess it depends on how you expect things to appear (that is, what
makes more sense in the mind of those who monitor your Nagios instance).
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Nagios-users mailing list
Nagios-users@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
