ITRS Opsview Cloud Documentation


The Orchestrator creates and distributes collection plans to Collectors within Opsview (actually to a Scheduler component on the Collector). The plans contain configuration and state information which allows the Collectors to schedule and monitor host/service checks, execute event handlers and send out notifications.

The Orchestrator also supports an HTTP API to allow for various real-time actions initiated from the UI (e.g. recheck host/service or set state).

Dependencies Copied

The Orchestrator requires access to the Database, MessageQueue, DataStore and LicenseManager. Please make sure these are installed, configured and running before you attempt to run Orchestrator.

You will also need to ensure the mysql client binary is installed.

Installation Copied

This component is deployed on the Master server when installing Opsview Monitor and must not be moved to another server.

Configuration Copied

The user configuration options should be set in /opt/opsview/orchestrator/etc/orchestrator.yaml. Default values are shown in /opt/opsview/orchestrator/etc/orchestrator.defaults.yaml, but changes should not be made here since the file will get overwritten on package update.

The below list shows the options that can be set. Note that any changes made to the component configuration file will be overwritten when opsview-deploy is next run.

Additionally, the service_check_defaults block controls the initial state of a Servicecheck when first added into the configuration (the state before the first check is performed)

The service_check_defaults configuration default is defined as follows:

    state: 0
    output: 'Service assumed OK - no results received'

Allowed states are:

State Meaning
0 OK

Changing the service_check_defaults has the following limitations:

Finally, for use with the Network Topology feature if included in your subscription, the following options are also available within the network_topology block:

For example:

  rpc_timeout: 60
  cluster_retries: 2

API Copied

The API operates over HTTP and supports the following commands:

Command Description
generate Generate collection plans (for example, for Apply Changes).
downtime Schedule or cancel downtime.
recalculate_bsm_statuses Recalculate bsm objects.
acknowledgement Acknowledgements, by name or object-id.
flow_query Execute a flow query using the flow collector.
process_result Process a manual result (set status).
get_collectors_for_hosts Return a map of collectors for hosts.
get_machine_node_data Return machine node data (from opsview-watchdog).
stats Receive general stats.
recheck Perform a recheck.
set_actions Sets actions such as enabling/disabling active checks.
send_snmptrap_trace Send set trace message to snmptraps collector.
get_notification_logs Returns notification logs from the Datastore back to the UI.
execute_remote_command Executes a remote command on the specified collector or will lookup the appropriate collector.

Management Copied

Configuration Copied

DPKGs Copied

Watchdog service files are now managed by the package, doing a remove would leave the watchdog service file behind with a .save extension. Purging the package will remove it. The package managed config file:


RPMs Copied

Watchdog service files are now managed by the package. Any modifications will be saved at upgrade and remove processes with the .rpmnew and .rpmsave extensions correspondingly.


Service Administration Copied

As root, start, stop and restart the service using:

/opt/opsview/watchdog/bin/opsview-monit <start|stop|restart> opsview-orchestrator
["Opsview On-premises"] ["User Guide"]

Was this topic helpful?