Applying configuration changes

Overview Copied

Apply Changes is an important feature in Opsview Cloud as it will need to be run to put configuration changes into production, and to add any custom uploaded monitoring scripts or plugins not provided by Opsview.

This is the process where Opsview Cloud reads the configuration and updates the running system to include the changes made since the last time the configuration files were loaded. For example, the addition of a new Host is not made active until the Apply Changes occurs. After this process, the changes will be visible in the user interface, dashboards and more.

The Apply Changes functionality is available as a modal window anywhere in Opsview Cloud. Users with RELOADVIEW permission will be able to view a badge in the navigation bar, as shown below, if there are pending changes:

Pending changes

The badge will signify the number of changes pending. If the number is over 10,000, a truncated value will be shown as 9999+.

You can click Apply Changes tile or the badge to open the Apply Changes window:

Apply Changes window

This modal window will display:

Audit Log Category

This allows you to see why changes need to be applied. By having this functionality, you can ensure that only a few users have the ability to perform this action and thus apply the changes. This is great for an ITIL environment where you want to ensure that changes are being done in a controlled manner, i.e. through the change control process and only applied on a Saturday evening within a downtime period.

Applying changes Copied

If you have the RELOADACCESS permission, you can click the Apply Changes button to start the process of applying changes.

If the change log system setting is enabled, you will be prompted to enter a change log message before the process of applying changes can start.

Change Log

After entering the change log message, click Save.

A progress bar will appear to signify the number of stages left to run and display a text of what the current stage is doing, as shown below:

Applying changes progress bar

The progress bar is calculated based on the size of your system and the number of collectors. If the process looks like it is going to take a while, you can close the window to continue using Opsview Cloud while the Apply Changes process is running.

While Opsview Cloud is applying your changes, the badge will turn into a spinning icon and you can hover over it to get more information:

Admin changes icon status

If other users visit the Apply Changes page while the process in progress, they will see the progress bar too.

It is impossible for two Apply Changes to be triggered simultaneously.

Once the changes are successfully applied, all users with this modal window open will be presented with a screen similar to the one below:

Changes applied

After successfully applying changes, the page in the background behind the modal will update if appropriate.

Note

If you are a multi-tenant user, the views will not contain user name information.

Once the changes are applied, a backup of the Opsview Cloud configuration database is automatically stored. A Restore button will be available so you can revert back to the previous configuration should the new one be inadequate.

Audit Log List

Note

You may wish to Apply Changes to Opsview Cloud, even if no changes are pending, in order to have the software detect that a newly added Service Check is generating graph data. By default, a Service Check that is generating graph data requires two Apply Changes: the first applies the Service Check to a Host, at which point it is executed and begins storing performance data on the file system; the second is then required to ensure that Opsview Cloud detects these new files and begins displaying the data within graph configuration windows, and also within investigate modes, sparkline graphs and more.

Process Copied

The Apply Changes process performs several key functions, such as:

Distributing uploaded monitoring scripts Copied

When new monitoring scripts (including plugins, notification scripts, and event handlers) are uploaded to Opsview, they are stored on the Orchestrator server and are not executable. The Apply Changes process takes these files and distributes them as required among all the collectors in the Opsview installation after running Apply Changes.

Standard and Remote Collectors receive the different types of uploaded files based on specific situations:

Note

Service Checks, Host Check Commands, or event handlers can also refer to additional plugins by having the file name of the plugin appear anywhere in the arguments, if the name begins with check_ or beta_check_.

Additionally, all Collectors always receive:

Warning

Uploaded monitoring scripts are not set up on the Orchestrator system for security reasons. Attempting to execute uploaded scripts directly on the Orchestrator will lead to failures and 'CRITICAL: no such file or directory' errors. This includes scenarios like a Host with uploaded plugins is monitored by the Master Monitoring Server Cluster or running custom Notification Methods on the Orchestrator.

Please note the following:

Size limitations Copied

There is a limit on the amount of data that can be sent from Orchestrator to Collectors during Apply Changes. The Apply Changes process has a 23MiB limit on the compressed size of the uploaded files per Collector. If the Collector’s files exceed this, the process will fail with an error: Compressed uploaded monitoring scripts were too large to distribute.

You can check the /var/log/opsview/opsview.log file on the orchestrator system for details on the file size and affected Cluster. To resolve this issue, either reduce the size of the uploaded files being sent, or decrease the number of uploaded files used by the affected Cluster.

Inactive Collectors Copied

When an entire cluster is inactive, any modifications made to uploaded monitoring scripts during Apply Changes will be held in a queue and applied once the cluster returns online. However, if only some collectors within a cluster are inactive, those specific collectors might not receive the uploaded monitoring scripts during Apply Changes. A similar message will appear in the Audit Log: Collector ‘<REF>' in cluster '<NAME>’ is inactive so will not receive new uploaded scripts. To resolve this issue, run Apply Changes once the Collectors are back online.

Deactivated Clusters Copied

If a Cluster has been deliberately deactivated in the UI (Configuration > Collector Management), any Collectors within that Cluster will be excluded from receiving any new or updated scripts through the Apply Changes process. After reactivating them in the UI, run Apply Changes again to send the new or updated scripts to the Collectors.

Failures Copied

If there is a failure with the Apply Changes process, the screen will show error messages for the administrator to resolve:

Failure when applying changes

Also, the badge will display an error:

Badge error icon

If the error is temporary (such as a component not running), resolve the error and then invoke Apply Changes again.

Note

You may need to re-log into Opsview Cloud to get the appropriate session information for the badge to appear.

Disconnections Copied

If your web browser is not connected to Opsview’s web server, a message will appear in the Apply Changes window.

Connection interrupted Copied

Connection interrupted

No internet connection Copied

No internet connection

Opsview Cloud will retry to connect and when successful, this message will disappear.

Note

The message may be different or it may not show at all, depending on your browser and OS, although it should always reconnect.

Troubleshooting Copied

Symptom: Warning message: "IP 192.168.10.22 has more than 1 host associated with it: host1, host2".

Solution: This occurs because there is more than one host that resolves to the same IP address. This is allowed in normal circumstances, except when SNMP Trap type Service Checks are associated with it. The reason is that an SNMP trap will be emitted from an IP address, and if that IP is associated to multiple Hosts, then a result will be sent to all Hosts associated to that IP address. The best way to resolve is that Host-specific Service Checks (such as SNMP Trap or other hardware Service Checks) are assigned to only one Host based on that IP address.

["Opsview"] ["User Guide"]

Was this topic helpful?