The following issues have been identified to exist within Opsview Monitor:
Opsview Monitor 5.4.0 has some hard-coded database table names which will affect any customer that has renamed their Opsview or Runtime databases from the default.. This has been fixed in Opsview Monitor 5.4.1.
After upgrading to Opsview Monitor 5.4.1, the script
cleanup_import must be run as the nagios user to ensure the import process can run as expected.
Sometimes the upgrade process can appear to hang with the following message:
[ ok ] Restarting web server: apache2 ... waiting . Reloading Opsview Watchdog
This will resolve itself if you wait long enough (typically around 10 minutes), but can also be fixed by opening a second session onto the server and running the following command as the "nagios" or "root" user.
pkill -f starman
The upgrade process should then continue within 30 seconds.
There is a known issue with Jasper Reporting for users who are using Chrome and have upgraded from Windows 8 to Windows 10. A workaround for this is to use an alternative supported browser such as IE11 or Firefox.
RPM platforms have been found to hang on upgrade due to an issue with watchdog and the new timeseries packages. In order to resolve this, the upgrade steps in section Upgrading CentOS or RHEL systems to 5.3.x should be followed
When using the
! character in host variable overrides you may see an error when the checks are run as scheduled, but works when using 'Troubleshoot'. This is a known problem which can be fixed by putting a
\ character before the
! (i.e. it becomes
When hosts are deleted in Opsview they automatically have downtime set on them for 7 days. However, if the server is later recreated then it will be associated with the downtime for the previous verison of the host, and this downtime cannot be deleted. This can be fixed by running the following query within the runtime database
select * from nagios_scheduleddowntime where object_id in (select object_id from nagios_objects where name1 = '<host-name>');
<host-name> in the query. When you are satisfied this is the correct host and downtime, it can then be deleted
delete from nagios_scheduleddowntime where object_id in (select object_id from nagios_objects where name1 = '<host-name>');