Welcome to docs.opsview.com

Moving a host between Opsview servers

It is very easy to move a host between Opsview monitoring servers, whether it is monitored by the master or a slave. (See the Menus ⇒ Advanced ⇒ Monitoring Servers page for a drag and drop interface, or by changing the Monitored By field on each individual host configuration page.)

Note: From Opsview 3.5.2, a slave will have the latest status information from the master sent on every reload. See the documentation for some limitations you should be aware of. The rest of this document is for Opsview versions prior to 3.5.2.

Nagios® Core stores its downtime and ack information within /usr/local/nagios/var/retention.dat on each server - this file is updated periodically and when nagios shuts down; it is reread when nagios starts up. Nagios Core writes what it finds into the Runtime database (data is not read back from the runtime database). Opsview's web UI uses the Runtime database to generate the host group hierarchy views.

Moving a host from Opsview master server to an Opsview slave server

The master server stores all status, downtime and acknowledgement information for all hosts. When an acknowledgement is set, or a downtime applied, even though all slaves are told at the time of the request, any slave that does not monitor that host ignores the request.

When a host is moved from the master to a slave, the configuration of the host is moved at Opsview reload time. Any status, downtime or acknowledgement information is not passed, so the slave starts monitoring the host from scratch and any problems discovered will be notified upon (if the configuration allows). However, the master still has this information so it may appear as though there is a descrepancy between what the slave is doing and what the master server is doing.

To fix this, all downtimes and acknowledgements for each host moved should be deleted and reapplied after the host has been moved and a reload done (if the reload is not done first, the slave will still not consider it to be monitoring the host, and will ignore the request).

This behaviour may be changed in the future or a script provided to enable the movement of the downtime and acknowledgements to the slave.

Moving a host between Opsview slave servers

This is very similar to the above section on moving a host from the master to a slave. Each slave acts as a discrete monitoring system and does not have (or need to know) any information about any host monitored by another slave or master. For this reason, moving a host will require downtime and acknowledgements to be removed and reapplied for each host moved.

Moving a host from an Opsview slave server to an Opsview master server

There is no impact or problem in moving a host from an Opsview slave system to the Opsview master. This is because the master has the state of the host already, including downtimes and acknowledgements.

Temporarily moving a host from an Opsview slave server to an Opsview master server

If all hosts that a slave monitors needs to be moved to the master on a temporary basis, the following steps should be performed:

  • Perform a reload (to save the current working configuration) - (1)
  • Disable notifications (Menus ⇒ Server ⇒ Process Info ⇒ Disable notifications)
  • Disable the slave in Opsview (Menus ⇒ Advanced ⇒ Monitoring Servers ⇒ Edit)
  • Move the hosts within Opsview from the slave to the master
  • Shutdown opsview on the slave
  • Perform a reload
  • Enable notifications

To revert:

  • Select the correct restore point from Menus ⇒ Server ⇒ Audit Logs from step (1)
  • Perform a reload

This assumes you do not add any more downtime or acknowledgements to the system during the time the slave is not in use, as these requested will not be processed by the deactivated slave.

Navigation
Print/export
Toolbox