The following issues have been identified to exist within the Opsview Monitor 6.0 Early Adopter (EA) release and will be addressed in subsequent update.
The following installation methods are not yet available but will be available at a later stage:
- In-place upgrade from Opsview Monitor 5.x
- Preinstalled images for Azure Portal and GoogleCloud.
The following installation methods are available for fresh installations:
If you are currently running an Opsview Monitor 5.x system you will need to follow the migration method.
If you are currently running an Opsview Monitor 6.0 Technical Preview 2 you can upgrade in place following this upgrade path.
There is no automated mechanism in Opsview Monitor 6.0 EA to synchronize scripts between the Opsview Monitor Primary Server and Collector Clusters. As an alternative, we recommend that you distribute the plugin scripts using configuration management tools like Chef, Puppet or Ansible, or follow our guidelines to copy the files manually.
The suite of plugins provided with the Microsoft Windows Base Opspack may in certain circumstances cause issues with CPU on the Windows machines that are being monitored.
The following modules are not available in the Opsview Monitor 6.0 EA release:
- SMS Gateway
- NetAudit - part of the Network Analyzer module - is not available.
Note that NetFlow is available.
Remote database installation is not enabled in the auto-installer. System Administrators can migrate the database post auto-installation by following the steps in the Database on a Different Server section of the documentation.
- Autodiscovery can only be run from the Primary Server.
- Test Service Checks will only execute from the Primary Server. If executed for a Collector Cluster, the output of FUNCTIONALITY NOT AVAILABLE will be seen. This also means that Service checks in the cloud-azure-network-watchers Opspack cannot be tested in the Troubleshooting pane. Users will experience a “Opsview Web Exception” message when trying to do so.
- Despite the UI/API currently allowing it, you should not set parent/child relationships between the collectors themselves in any monitoring cluster, as collectors do not have a dependency between each other and are considered equals.
- Notifications for BSM are not implemented in this release. Access Control changes relating to the BSM object will not re-validate pending notifications.
- Notifications for flapping states are not implemented in this release.
- Sticky Acknowledgements lose their “sticky” status after Reload.
- Acknowledgements are not preserved in case of a Collector failure and automatic recovery process.
- After installating opsview-sshtunnels, this component doesn't start with a message such as "'opsview-sshtunnels' start action failed" - please contact the Opsview Customer Success team to get an up-to-date-package.
- Changing the flow collectors configuration in Opsview Monitor currently requires a manual restart of the flow-collector component for it to start working again.
- In some cases, disabled service checks get re-enabled if opsview-scheduler goes down.
While inputting non-UTF-8 characters into Opsview Monitor will not generate any problem, the rendering of those characters in the user interface may be altered in places such as free text comments.
- If the Reload is not performed within 30 minutes of the Reboot, the service check state over the elapsed time will be lost but Opsview Monitor will then resume monitoring your infrastructure as normal.
- It may also happen that the syslog presents errors that point to connection issues with the opview components, you need to restart the opsview-loadbalancer service.