I replaced both of my slaves, now it seems that all checks are handled by my
master server. The slaves are setup correctly, show as "up" in OV, are part
of the "slave cluster", and all hosts are set to be monitored by the "slave
cluster". Reloading the config elicits the expected push of config files as
well as the standard service restart on the cluster nodes. The process for
rebuilding my slaves went like this.
1. Deleted the "Slave Cluster" entry from the "Monitoring Servers" page and
reloaded the config.
2. Once i was sure the monitoring was all being handled by the master and
everything was good, i deleted the slave node "Host" entries and reloaded
the config.
3. Deleted the old VMs and built new slaves with the same IPs and hostnames
and such.
4. Configured them as one normally would, added the nagios user, copy ssh
keys, created host entries and all that.
5. created the slave cluster in OV, added the 2 nodes, did the manual
send2slaves test and push as well as the ./install_slave bit, which went off
without a hitch.
6. Reloaded config, and saw that the slave cluster was showing as up and
that reloading config triggered push and restarts.
7. Drag all hosts from "master" to "slave cluster" in monitoring servers
page and reload config.
Some things i've tried to get the slaves to do the check is manually
toggling the "monitored by" setting back to master, reload, then back to
slave cluster and reload. I have not added any new hosts to be monitored yet
to see if they get monitored by the slaves.
I know the checks are being done by the master because I'm tailing the
nagios.log on all the ov boxes, so I see that only master is doing work,
slave still print out some "service notification" messages as well as loggin
restarts of nagios processes etc.
Any ideas would be greatly appreciated.
--
Ben Lutgens
Linux / Unix System Administror
Three of your friends throw up after eating chicken salad. Do you think:
"I should find more robust friends" or "we should check that refrigerator"?
-- Donald Becker, on vortex-bug, suspecting a network-wide problem
_______________________________________________
Opsview-users mailing list
[email protected]
http://lists.opsview.org/listinfo/opsview-users
