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
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
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.
As root, start, stop and restart the service using:
/opt/opsview/watchdog/bin/opsview-monit <start|stop|restart> opsview-resultsdispatcher
Updated almost 4 years ago