Results Dispatcher

Description

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.

Dependencies

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.

Installation

Refer to Advanced Automated Installation.

Configuration

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.

Management

Configuration

DPKGs

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

RPMs

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