ITRS Opsview Cloud Documentation

Managing clusters and collectors

Viewing Clusters and Collectors Copied

Clusters and Collectors (also called Monitoring Clusters and Monitoring Collectors) can be viewed in the Configuration > Monitoring Collectors page under the respective tab. Only Clusters which the user has configuration access will be visible, and any Collectors not in those Clusters will be hidden. To view unregistered Collectors, the user must have access to “All Monitoring Clusters” selected. For more information, see Role Configuration.

Prerequisites Copied

These are the detailed steps and prerequisites before adding new collector servers to a single-box system, and new collector servers to an existing Opsview Monitor system with multiple servers and existing collectors.

Adding collector servers Copied

To a single server system Copied

To add new collector servers to an existing single-server Opsview Monitor system, open the /opt/opsview/deploy/etc/opsview_deploy.yml file, and add the following lines.


Do not change the existing lines in opsview_deploy.yml.
      opsview-de-1: { ip: }

Change opsview-de-1 and to the hostname and IP address of your new collector, and give your collector cluster a name by changing collectors-de.

You may add multiple collector-clusters, and multiple collectors under each cluster such as:

      opsview-de-1: { ip: }
      opsview-de-2: { ip: }
      opsview-de-3: { ip: }

      opsview-fr-1: { ip: }
      opsview-fr-2: { ip: } 
      opsview-fr-3: { ip: }
      opsview-fr-4: { ip: }
      opsview-fr-5: { ip: }


There should always be an odd number of nodes within a collector cluster: 1, 3, and 5. This is to help with resiliency and avoid split-brain issues. In an even number cluster, if half the nodes go down the other half will stop functioning as the cluster within opsview-datastore and opsview-messagequeue will have no quorum and so will not accept updates until the other cluster members are restored. We do not support clusters with only two collectors for the above reason.

In the example configuration above, two new collector clusters called collectors-de and collectors-fr are created.

The collectors-de cluster has the minimum requirement of 3 collector nodes, while collectors-fr has 5 collector nodes, with hostnames and IP addresses provided.

After modifying opsview_deploy.yml, run opsview deploy as follows:

cd /opt/opsview/deploy
./bin/opsview-deploy lib/playbooks/check-deploy.yml
./bin/opsview-deploy lib/playbooks/setup-hosts.yml
./bin/opsview-deploy lib/playbooks/setup-infrastructure.yml
./bin/opsview-deploy lib/playbooks/setup-opsview.yml

To register your collector and use the suggested Host Templates and associated Variables needed for those templates, run:

./bin/opsview-deploy lib/playbooks/setup-monitoring.yml

Click Apply Changes within the UI after this has completed successfully for this step to take effect.

If you receive Service Check alerts similar to the below, then the above steps has not been run.

CRITICAL: Could Not Connect to localhost Response Code: 401 Unauthorized

To a multiple server system Copied

If you already have some collectors and you want to add new collectors, open /opt/opsview/deploy/etc/opsview_deploy.yml on your deployment server (which is typically opsview host with orchestrator and opsview-web) and add new collector clusters or collector hosts after existing ones such as:

      existing-host1: { ip: }
      new-host1: { ip: }
      new-host2: { ip: }

      new-host3: { ip: }
      new-host4: { ip: } 
      new-host5: { ip: }

In the example above, 5 new collector hosts exist (new-host1, new-host2, new-host3, new-host4 and new-host5), and 1 new collector cluster (new-collector-cluster1) have been added.

After modifying opsview_deploy.yml, run opsview deploy as follows:

cd /opt/opsview/deploy
./bin/opsview-deploy lib/playbooks/check-deploy.yml
./bin/opsview-deploy lib/playbooks/setup-hosts.yml
./bin/opsview-deploy lib/playbooks/setup-infrastructure.yml
./bin/opsview-deploy lib/playbooks/datastore-reshard-data.yml
./bin/opsview-deploy lib/playbooks/setup-opsview.yml

If you wish to speed up this process you may specify the collector cluster you are updating or creating. The best way to do this is to specify the collector cluster using the minus lowercase “-l” (l for Lima) option

You may also use the collector names within double quotes if these are new collector clusters For a single new collector cluster (a cluster or one), you may use the collector name or names of the collectors

This is also best practice for removing a collector from a cluster.

To register your collector and use the suggested Host Templates and associated Variables needed for those templates, run:

./bin/opsview-deploy lib/playbooks/setup-monitoring.yml

Collector variables Copied

You may set specific component configuration against any Collector. Settings may be rolled out to individually or to all Collectors by utilising /opt/opsview/deploy/etc/user_vars.yml and /opt/opsview/deploy/etc/opsview_deploy.yml. In this example we shall look at setting specific examples against the opsview-executor configuration for all collectors, then for the existing-collector1 server.

To push out the configuration against all collectors upon a deployment, you will need to have a “ov_component_overrides” section and an applicable component section specified such as “opsview_executor_config” - this is set within the /opt/opsview/deploy/etc/user_vars.yml. These changes are applied to the components <opsview-component>.yaml configuration file, so for the executor this is /opt/opsview/executor/etc/executor.yaml. The below will change the system defaults for initial_worker_count to 4 (a system default of 2) and max_concurrent_processes to 10 (a system default of 25).

    initial_worker_count: 4
    max_concurrent_processes: 10

Then run a deployment using the ‘setup_everything.yaml` playbook to push out this configuration to all Collectors.

If the configuration is only required on one collector then modify the /opt/opsview/deploy/etc/opsview_deploy.yml to add the overrides into the vars: section for specific collector, as follows:

              initial_worker_count: 4
              max_concurrent_processes: 10

Instead of running the whole Deploy process, use the collector-install.yml playbook against the specific collector (as detailed in an above section). If multiple collectors within the same Cluster are modified, ensure you run the playbook against all of them at the same time by using the option -l collector1,collector2,collector3.

Cluster Health Copied

The Configuration > Monitoring Collectors page shows details on the health of both individual collector nodes and each Cluster.

Clusters tab Copied

The Status column shows the current state of the cluster. Possible values are:

Cluster Health Alarms Copied

The table below describes the possible alarms that will be shown when users hover over the status of a DEGRADED cluster. These alarms refer to conditions of the following Opsview components:

Alarms Description Suggestions/Actions
All [Components Name] components are unavailable. For example, all opsview-executor components are unavailable. Master/ Orchestrator server can’t communicate with any [Components Name] components on collector cluster. This may be because of a network/communications issue, or because no [Components Name] components are running on the cluster.
This alarm only triggers when all [Components Name] components on the collector cluster are unavailable, since a cluster may be configured to only have these components running on a subset of the collectors. Furthermore, the cluster may be able to continue monitoring with some (though not all) of the [Components Name] components stopped.
To resolve this, ensure that the master/orchestrator server can communicate with the collector cluster (i.e. resolve any network issues) and that at least one scheduler is running e.g. SSH to collector and run /opt/opsview/watchdog/bin/opsview-monit start [Component Name]
Not enough messages received ([Components Name 1] → [Components Name 2]): [Time Period] [Percentage Messages Received]%.
For example, Not enough messages received (opsview-scheduler → opsview-executor):[15m] 0%.
Less than 70% of the messages sent by [Components Name 1] have been received by [Components Name 2] within the time period. This could indicate a communication problems between the components on the collector cluster, or that [Components Name 2] is overloaded and is struggling to process the messages it is receiving in a timely fashion.
For example, 0% messages sent by the scheduler have been received by the executor within a 15-minute period.
If 0% of the messages sent have been received by [Components Name 2] and no other alarms are present then this may imply a communications failure on the cluster. To resolve this ensure that the collectors in the cluster can all communicate on all ports and that opsview-messagequeue is running on all the collectors without errors.
Alternatively, this may be indicate that not all the required components are running on the collectors in the cluster. Please run /opt/opsview/watchdog/bin/opsview-monit summary on each collector to check that all the components are in a running state. If any are stopped then run /opt/opsview/watchdog/bin/opsview-monit start [component name]to start them.
If > 0% messages sent have been received by [Components Name 2], then this likely implies a performance issue in the cluster. To address this you can reduce the load on the cluster: reduce the number of objects monitored by that cluster, reduce the number of checks being performed on each object in the cluster (i.e. remove host templates/service checks), increase the check interval for monitored hosts, increase the resources on the cluster, add additional collectors to the cluster, improve the hardware/resources of each collector in the cluster (i.e. investigate bottleneck by inspecting self-monitoring statistics and allocate additional CPU/memory resources as needed).


For a fresh collector/cluster which has just been setup or which has minimal activity, the “Not enough messages received” alarm will be suppressed to avoid unnecessary admin/user concern. This does not impact the “All [Components Name] components are unavailable” alarm, which will still be raised for a offline collector.

Network Topology Copied

If your subscription includes the Network Topology feature, the Configuration > Monitoring Collectors page allows you to enable or disable regular Network Topology detection on a per-cluster basis.

Clusters tab Copied

The Network Topology column shows whether regular Network Topology detection is enabled for each cluster.

  1. To enable, click the menu icon and Features Enabled:

  2. Then click the Network Topology toggle:

    Toggle network topology

  3. Once Network Topology detection has been carried out and a map is ready to be displayed for a particular cluster, it can be accessed by clicking the menu icon for that cluster and then View Topology:

For further information on the contents of the Network Topology map, refer to Viewing Network Topology Maps.

Collectors tab Copied

The Status column shows the current state of the collector. Possible values are:

Collectors tab

Deleting a cluster Copied

The steps are slightly different depending on the size of the cluster.


If you have deleted a collector but then you want to register it again, you will not see it become available in the Unregistered Collectors grid until you stop the Scheduler on that collector for at least a whole minute and then restart it.

Deleting a collector in a single-collector cluster Copied

  1. Disable the cluster by clicking Configuration > Monitoring Collectors > Clusters.
  2. Edit the cluster then uncheck the ‘Activated’ box and click Submit Changes. You will then need to Apply Changes.
  3. Delete the cluster by clicking Configuration > Monitoring Collectors > Clusters.
  4. Delete the collector by clicking Configuration > Monitoring Collectors > Collectors.
  5. Delete the collector as a monitored host by clicking Configuration > Hosts.
  6. Perform an Apply Changes.
  7. Edit your deploy files (opsview_deploy.yml, user_vars.yml, and others as appropriate) to either comment out or remove the lines for the deleted collector.

Deleting a Collector in a multi-collector Cluster Copied

  1. Remove the Collector from its Cluster (Configuration > Monitoring Collectors > Clusters).
  2. Edit the Cluster and deselect the Collector you wish to remove so only the Collectors you wish to keep in the Cluster are highlighted, then click Submit Changes.
  3. Delete the Collector (Configuration > Monitoring Collectors > Collectors).
  4. Delete the Collector as a monitored host (Configuration > Hosts).
  5. Perform an Apply Changes.
  6. Edit your deploy files (opsview_deploy.yml, user_vars.yml, and others as appropriate) to either comment out or remove the lines for the deleted Collector.
  7. Run a full deploy against the Cluster, e.g. /opt/opsview/deploy/bin/opsview-deploy -l collector1,collector2,collector3 /opt/opsview/deploy/lib/playbooks/setup-everything.yml.

Upgrading a collector Copied

Upgrading collector is as simple as upgrading all Opsview packages on the Collector Server. To avoid any downtime shut down the connection from Collector to Master MessageQueue Server, upgrade all packages and reset the system. Once the connection is restored the Collector will automatically join the Cluster and you can now perform upgrade of the other Collectors.

Managing collector plugins Copied

In a distributed Opsview Monitor system, monitoring scripts on the Collectors may become out of sync with the ones on the Orchestrator when:

In such cases, the monitoring scripts folder (/opt/opsview/monitoringscripts) on the Orchestrator needs to be synced to all of the Collectors by using an ansible playbook called sync_monitoringscripts.yml.

The sync_monitoringscripts.yml playbook uses rsync to send appropriate updates to each Collector (it will be installed automatically if required) while excluding specific sets of files.

The following directories and files (relative to /opt/opsview/monitoringscripts) are not synced:


For example, using the above exclude list, files within the /opt/opsview/monitoringscripts/lib/ directory and specific files such as /opt/opsview/monitoringscripts/etc/notificationmethodvariables.cfg won’t be synced.

Additionally, if the Collector does not have the same OS version as the Orchestrator, only statically linked executable files and text-based files will be synced. This is to ensure binaries used on the Orchestrator are not synced with an incompatible Collector. For example, an AMD64 binary will not be sent to an ARM32 based Collector.

Prerequisites Copied

SSH keys are setup between the Orchestrator and collectors (this should already be in place if Opsview Deploy was previously used to install or update the system).

How to sync Copied

Run the following commands as root on the Orchestrator:

cd /opt/opsview/deploy/
bin/opsview-deploy lib/playbooks/sync_monitoringscripts.yml

Limitations Copied

If your deploy server is not Orchestrator, you can run the same commands on your deploy server but SSH keys must have been setup between the Orchestrator and collectors for the SSH users defined for your collectors in your opsview_deploy.yml file.

["Opsview On-premises"] ["User Guide"]

Was this topic helpful?