Welcome to docs.opsview.com

Status and Reload

This screen shows whether Opsview is running or not. In a production environment, this will always be running.

When you click the Reload Configuration button, this will initiate a reload of Opsview, taking all the configuration changes and updating all the relevant configuration files.

If there were errors from the previous reload, these will be shown here.

Changes to Opsview's configuration during a reload may cause failures - these will be caught and displayed on this screen.

The reload screen also shows the number of changes that will be applied if a reload is performed. That link can be selected, which will result in the audit log displaying the outstanding changes:

When the reload has completed successfully, a backup of the Opsview configuration database will be done. The audit log table will show a Restore button which you can use to restore the last successful configuration. (Note, backups run overnight will not create a Restore button.)

Reload Messages

There maybe warning or critical messages that get displayed after a reload.

IP has more than 1 host associated with it: host1, host2

This occurs because there is more than 1 host that resolves to the same IP address. This is allowed in normal circumstances, except when SNMP traps service checks are associated to it. The reason is that if an IP address is associated to a host multiple times, then one snmp trap alert will be sent to all hosts associated to that IP address.

The best way to resolve is that host specific checks (such as SNMP traps or other hardware checks) are assigned to only one host based on that IP address.


Reloading requires the opsviewd process to be running. If you have issues after a reboot, ensure that MySQL is started before starting Opsview.

A reload flag is set to stop multiple reloads from running simultaneous. If the reload does not complete, check for the file /usr/local/nagios/var/rw/reload_flag.

A reload will generate messages in /var/log/opsview/opsviewd.log like:

[2010/09/02 11:43:48] [opsviewd] [INFO] Running 'web_reload' with args:
[2010/09/02 11:43:51] [create_and_send_configs] [INFO] Starting overall
[2010/09/02 11:43:56] [create_and_send_configs] [INFO] Ending overall with error=0
[2010/09/02 11:44:08] [ndoutils_configdumpend] [INFO] Start
[2010/09/02 11:44:12] [ndoutils_configdumpend] [INFO] End

Configuration Generation Output

You can see the last configuration generation error in /usr/local/nagios/var/rw/config_output. The last successful configuration generation output will be in /usr/local/nagios/var/rw/config_output.okay.

This includes timings for each section. If there is one section which is taking a long time, this may highlight an area for optimisation.

Reload Process Management

The reload process kicks off several parallel jobs. You can see the workflow in the debug file: /usr/local/nagios/var/log/create_and_send_configs.debug.

This shows the dependencies and the durations of the jobs.

We have seen one instance where a poorly configured DNS server on one slave was slowing down the entire reload process, as all slaves must finish successfully for dependent jobs to continue.

Slow Reload Times

If you find that your Opsview server has a long reload time, these are the things to look at:

For further investigation, you can raise in our forums or raise a support ticket.

Slow Post-reload Times

If you find that there is a large delay between the reload finishing and new status results coming in, you can check the opsviewd.log file for the following:

[2012/01/06 12:13:32] [import_ndologsd] [WARN] Import of 1325852003.546428, size=968865, took 8.60 seconds > 5 seconds

This shows that there was a large import file (968865 bytes) which took 8.6 seconds to import.

After a reload, a large import file is generated (to hold all the Nagios configuration) which needs to be imported into the Runtime database.

You can enable debug mode for the ndo log files by changing the Log4perl.conf file and uncommenting:


Within 30 seconds, a new directory in /usr/local/nagios/var/ndo.archive will be created with a copy of every NDO log that is sent to the database. This can be useful for debugging and replaying the import of that NDO log.

Remember to switch this debugging off!