These docs are for v6.6. Click to read the latest docs for v6.7.

Results Dispatcher


Receives messages (e.g. PassiveResultMessages) and:

  • Forwards them to the correct Collector, using the host to collector mapping stored in the datastore when generating or re-generating collection plans.

  • Messages must either be acknowledgements, downtime, Job results or snmptraps.

  • Acknowledgement messages have special functionality in that they come in with 'service_object_id_list' and/or 'host_object_id_list' set, then are re-sharded according to 'host_id' and sent out to the Collectors (now with 'host_id' set).

  • For other messages, if 'host_id' and 'object_id' are set, the messages are sent direct to the correct Collector. If not, then the 'host_id' and 'object_id' are looked up using 'hostname' and 'servicecheckname' fields, updates the message before re-dispatching.

  • Supports multiple worker sub-processes, but is launched by default with only one.


The Results-Dispatcher requires access to the MessageQueue, Registry, DataStore and Core Utils. Please make sure these packages are installed, configured and running before attempting to run opsview-resultsdispatcher.

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


Refer to Advanced Automated Installation.


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

The following options can be set:

  • master_database_connection: The connection to the master database server.
  • opsview_database_name: The name of the Opsview configuration database.
  • runtime_database_name: The name of the Opsview runtime database.
  • results_in_queue: The message-queue configuration to receive incoming results.
  • collector_queue: The message-queue configuration to send messages to the collectors.
  • master_store: The data-store configuration.
  • registry: Connection configuration for the Registry.
  • logging: Component logging configuration.




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 files are as follows

  • /opt/opsview/watchdog/etc/services/opsview-resultsdispatcher.conf


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.

  • /opt/opsview/watchdog/etc/services/opsview-resultdispatcher.conf

Service Administration

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

/opt/opsview/watchdog/bin/opsview-monit <start|stop|restart> opsview-resultsdispatcher