🚧

Before upgrading to Opsview Monitor 6.4

Prior to installing or upgrading Opsview, please read the Prerequisites and the relevant New Installation or In-Place Upgrade guides.

Questions? - Open a Support ticket with our technical team through the Support Portal.

Short on2ndsource to perform an upgrade or migration? - Let our technical experts do this for you, followed by a full health check to ensure your environment is running efficiently. Available for a limited time, we are offering significant discounts on assisted upgrades.

For Major and Minor version upgrades, please get in touch with your Account Manager to schedule the upgrade while the offer lasts.

Update: 28 February 2022 (6.4.33)

Defect Fixing

• Fixes to Microsoft 365 checks due to deprecated API
• Fixes to WMIC due to Microsoft Windows DCOM hardening

Update: 12 January 2022 (6.4.32)

Defect Fixing

• Log4j security vulnerability

Update: 21 December 2021 (6.4.31)

Defect Fixing

• Log4j security vulnerability

Update: 21 December 2021 (6.4.30)

Defect Fixing

• Fix security issues with possible SQL injection in rest/snmptrap/debug

Update: 28 June 2021 (6.4.29)

Defect Fixing

This release amends the rules for what is classed as a degraded collector, so that restarting components no longer marks a cluster as degraded.

Update: 18 May 2021 (6.4.28)

Defect Fixing

This release improves the performance characteristics of the opsview-datastore services used on Collectors. For more details see here.

Update: 15 April 2021 (6.4.27)

Defect Fixing

This release resolves and issue where manual license activation was disable in the UI. For more details see here.

Update 9th March 2021 (6.4.26)

Defect Fixing

This release makes further performance improvements to the opsview-datastore service on both Collectors and the Orchestrator. For more details see here.

Update 15 February 2021 (6.4.25)

Defect Fixing

Resolve the issue where the NetFlow dashlets in the Dashboard regularly timed out

Security Enhancements

Resolve various vulnerabilities within NetAudit

For more details see here.

Update 2 February 2021 (6.4.24)

Defect Fixing

This release also addresses an additional number of general defects across Opsview Monitor. For more details see here.

Update: 7 January 2021 (6.4.23)

Security Enhancements

• The way user sessions are handled in Opsview Monitor has been improved, as part of this update considering security best practices. One of the most relevant changes is that the number of concurrent sessions per user has been limited to 10 by default.

  To change the default value, edit the max_sessions variable in /opt/opsview/sessionmanager/etc/sessionmanager.yaml and restart the session manager component in watchdog /opt/opsview/watchdog/bin/opsview-monit restart opsview-sessionmanager

• CouchDB instances now no longer listen on all interfaces from their HTTP servers (port 5984) by default. This means that the REST API and the Fauxton web UI are only accessible from the servers running CouchDB. These can be more easily accessed if you have SSH access to the servers by setting up an SSH tunnel. Once the tunnel is set up, the API and Fauxton will be accessible at localhost:5984/.
  ssh -L 5984:localhost:5984 <couchdb_server>

Monitoring Capabilities - Opspacks

• VMware vSphere Monitoring:

  Significant performance improvements for execution time, cpu time and memory utilisation achieved across all Host Templates when running with opsview-cachemanager.

  Summary text updated for the following service checks for clarity and readability (reported stats and performance data unchanged):

  • vSphere - Host - Network Adapters
  • vSphere - Host - Temperature
  • vSphere - Host - Port Group Summary
  • vSphere - Host - Health Issues
  • vSphere - Host - Datastore Usage
  • vSphere - Host - Datastore Used
  • vSphere - Host - Datastore Latency
  • vSphere - Host - Datastore VM Observed Latency
  • vSphere - Host - Datastore Read/Write
  • vSphere - Guest - Datastore Usage
  • vSphere - Guest - Datastore Used
  • vSphere - Guest - Datastore Latency
  • vSphere - Guest - Datastore Read/Write

  Improved error handling and messages for the following service checks:

  • vSphere - Datastore - Provision
  • vSphere - Datastore - Disk Usage
  • vSphere - Datastore - Summary
  • vSphere - Host - Datastore Usage
  • vSphere - Host - Datastore Used
  • vSphere - Guest - Datastore Usage
  • vSphere - Guest - Datastore Used

• HAProxy Monitoring:

  Now supports the use of TLS with or without certificates when connecting to HAProxy via the new HAPROXY_CERTIFICATES variable.

• [OpenStack Opspack] (https://www.opsview.com/product/system-monitoring/cloud/openstack) is now compatible for monitoring the following version of OpenStack:

Defect Fixing

This release also addresses an additional number of general defects across Opsview Monitor. For more details see here.

Release: 28 October 2020

Opsview Monitor Python 3 Migration

Python version 2.x was officially deprecated on January 1, 2020. Python packages have ended or will end support, and new packages will not provide support for Python 2. For this reason and in order to leverage continuous Python third-party security vulnerabilities fixes and overall packages improvements for the many Python packages that are used within Opsview Monitor, Opsview has migrated Opsview Monitor to be compatible with Python 3.6.

📘

Important Notes

• If you have written your own monitoring scripts, notification scripts or integrations using the Python 2 binaries provided by the opsview-python package instead of your own Python implementation, you might be impacted by Opsview Monitor Python 3 migration. Before upgrading to Opsview Monitor 6.4, we recommend migrating your own monitoring scripts, notification scripts or integrations to use the Python 3 binaries provided by opsview-python3 package or your own Python implementation.

• Internal Performance Tests have shown that opsview components running on Python 3 could utilise on average up to 8% more CPU and 7% less RAM than their counterparts running on Python 2

• To remove the Python 2 binaries provided by the opsview-python package from your Opsview Monitor system after upgrading to 6.4, please run the following command as root on your Opsview deployment host (Where opsview-deploy is installed; often the master host)
  cd /opt/opsview/deploy && bin/opsview-deploy lib/playbooks/python2-uninstall.yml

Security Enhancements

This release provides Opsview Monitor users with a more robust system by improving security aspects of access privilege, data sanitization and configuration. The following list provides an overview of the different security enhancements:

• Improve restrictions on SSH shell access on the Master Server from Collectors
• Security configuration enhancements to enforce password strength
• Improve areas of the product where it was possible to perform Cross-site Scripting and MIME sniffing
• Fix vertical privilege escalation and insufficient user lockdown vulnerabilities
• Restrict access privileges for the opsview user during run-time
• Upgrade 3rd party libraries containing security vulnerabilities
• Improve areas of the product where it was possible to perform OS command injection attacks
• Improve cookies management to avoid exposing possible confidential or private information and taking into consideration security best practices
• Reassess and implement Idle Timeout periods consideration security best practices
• Improve SQL related error messages to avoid exposing possible confidential or private information and taking into consideration Security best practices
• Improve data validation, filtering and encoding in different areas of the product
• Maintain Opsview user password history so a new password is not the same as the current or previous (N) passwords
• Set certain HTTPS pages not be cached by the browser by following Security best practices
• Security improvements to ensure all access to CouchDB is restricted by authentication
• TLS v1.0 and TLS v1.1 are now disabled by default for all back-end components to improve security.
  • Note: To change these options, or set a custom cipher suite override opsview_tls_versions_disabled and/or opsview_tls_cipher_suite in user_vars.yml

📘

Import Note

For customers running Opsview Monitor on CentOS 7 Operating System, it is recommended to:

• Upgrade the Linux kernel version to at least 4.4.x
• Upgrade the version of PHP to at least 7.3.1
• Upgrade the version of OpenSSH to at least 7.4p1-21
• Disable Diffie-Hellman based keys using less than 2048-bits OR disable DH keys and use only Elliptic-Curve based Diffie-Hellman keys (ECDH)
• Kernel and PHP package upgrades may require configuring additional repositories as CentOS 7 do not have the required packages by default

Contact your System Administrator to verify current versions and perform upgrades if required.

New BSM Interface

Opsview is committed to continuously improving users' experiences. In this release, we are pleased to make the New BSM interface available to Opsview Monitor customers. The new BSM views enable users to more rapidly and interactively find issues impacting Business Services by providing visibility all the way down to the Service Check level. It also allows users to have a clear and unique picture of only the problems impacting a Business Services to facilitate faster time to resolution when something goes wrong.

This New BSM interface provides a much more powerful and insightful view to Senior Management who will be delighted with the ability to see real-time status of the most critical Business Services at a glance.

For more details see BSM Views user documentation

Monitoring Capabilities - Opspacks

• Cisco Unified Computing System (UCS) is a data center server computer product line composed of computing hardware, virtualization support, switching fabric, and management software. This Opspack provides a selection of Host Templates, ranging from the top-level Fabric Host Template to lower-level monitoring via Host Templates for Chassis and Servers, as well as a Custom Query Host Template, allowing you to monitor all aspects of your Cisco Unified Computing System. The following Host Templates are currently available as part of the Cisco - UCS Opspack.
  • Infrastructure - Cisco UCS - Fabric
  • Infrastructure - Cisco UCS - Rack
  • Infrastructure - Cisco UCS - Blade
  • Infrastructure - Cisco UCS - Chassis
  • Infrastructure - Cisco UCS - Custom

For more information see the Cisco - UCS Opspack.

• OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources throughout a datacenter, all managed through a dashboard that gives administrators control while allowing their users to provision resources through a web interface. This Opspack will provide Host Templates to monitor a variety of installed OpenStack services. The following Host Templates are now fully available as part of the Cloud - OpenStack Opspack.

  • Cloud - OpenStack - Keystone
  • Cloud - OpenStack - Nova Server
  • Cloud - OpenStack - Nova Hypervisor
  • Cloud - OpenStack - Cinder
  • Cloud - OpenStack - Neutron
  • Cloud - OpenStack - Swift

  For more information see the Cloud - OpenStack Opspack page.

• Cloud Azure:

  • "Azure - SQL" Opspack has been replaced by 5 new Host Templates part of the Cloud - Azure Opspack to account for different database instance types available in Azure. As part of an upgrade, any host that has the old "Cloud - Azure - SQL" Host Template will default to the new "Cloud - Azure - SQL - DTU" Host Template. This may not be the correct Host Template for your SQL database so you will need to manually verify and change the Host Template to another from the list below, as required. The new Host Templates are:

    • Cloud - Azure - SQL - DTU
    • Cloud - Azure - SQL - DWU
    • Cloud - Azure - SQL - Hyperscale
    • Cloud - Azure - SQL - Serverless
    • Cloud - Azure - SQL - vCore

  • "Azure - Elastic Pool" Opspack has been replaced by the new Cloud - Azure - Elastic Pool Host Template within the Cloud - Azure Opspack. This new Host Template supports configuration for both DTU and vCore based Elastic Pools, although some service checks may return UNKNOWN if they are not applicable to your selected elastic pool type. Note that, as part of an upgrade, any Opsview host using the old "Cloud - Azure - Elastic Pool" Host Template will default to use the new Host Template with DTU-based checks. This may not be the correct setting for your elastic pool so you will need to manually verify and change the Elastic Pool Type field of the AZURE_EP_SETTINGS host variable.

    For more information see the Cloud - Azure Opspack page.

  • Cloud - Azure - Generic, Cloud - Azure - Internet of Things Opspacks have been updated to utilise the Python binary provided by the opsview-python3 package, and the required python libraries are now bundled with this package. Therefore, you no longer need to manually install the nagiosplugin, azure and azure-monitor python libraries in your own Python implementation or user environment for these Opspacks to function.

• All Services Checks related to SNMP-MIB-II Host Template are now using Opsview Cache manager, improving the consistency of metrics in a distributed environment.

• All Services Checks related to Host Templates part of Cloud - Azure Opspack are now using Opsview Cache manager, making them more memory-efficient.

General Product Notes

• The graph legend panel part of the graph in the Investigate window, Graph Tab and Performance Graph Dashlets will now display Min, Avg and Max values of all the visible plots.

• SNMP MIB-II Host Template and Host query are now IPv6 compatible

  • Introduced two new arguments for the Interface Poller service check --use_ipv4 | -4 and --use_ipv6 | -6 which explicitly bind the Hostname provided to a specific IP version when specified. If neither of those flags is provided, the domain name resolution will determine the default IP version.
  • SNMP MIB-II related services now auto-detect the correct IP version (IPv4 / IPv6).

• The Apply Changes process has been optimised so that the object lookup within the notification profile has improved up to 70x depending on system configuration. Enterprise customers who monitor a large number of devices will experience significant improvement. This optimisation also addressed the following defects:

  • A role with only NOTIFYSOME will now work correctly for notifications
  • Host notifications are now correctly removed, where a relevant service does not belong on it

  For the latter, if you select Host Group “USA” with Service Group “Database”, then only hosts that have a service check in the Database service group will be added (rather than all hosts in “USA”). However, some systems have notification profiles configured in this way, so as part of the upgrade we will automatically convert any notification profiles that have no Service Groups to be “Service Groups: All” but set the Service Check notifications states to be none. This will apply to notification profiles with the following configurations:

  • Host Groups configured with no Service Groups
  • Host Groups: All with no Service Groups

• As part of the metadata field, the output data from the Results Exporter component will now contain the name of the Host Machine that the Service Check was run on.
  For more information. See Exporting Results - Supported Field Section

• As of this release, the Reporting module now requires Chromium to be installed in order to render reports. Opsview Deploy will automatically set up an EPEL (Extra Packages for Enterprise Linux) repository on all Opsview Monitor Servers to pull the chromium package down. In some cases, manual configuration could be required.
  See Advance Development - Report Module Installation for more information.

• The following variable, which affects the MySQL or MariaDB database, can be configured from deploy’s user_vars.yml. Set with opsview_database_max_allowed_packet: 16M

  The default is 16M. We recommend not to use a lower value.

  If you are upgrading from Opsview Monitor 6.3, you may have changed this value in opsview_database_config_overrides - a setting in this file will take priority over opsview_database_max_allowed_packet

Defect Fixing

This release also addresses an additional number of general defects across Opsview Monitor. For more details see here.