Opsview 6.8.x End of Support
With the release of Opsview 6.11.0 on February 2025, versions 6.8.x have reached their End of Support (EOS) status, according to our Support policy. This means that versions 6.8.x will no longer receive code fixes or security updates.
The documentation for version 6.8.9 and earlier versions will remain accessible for the time being, but it will no longer be updated or receive backports. We strongly recommend upgrading to the latest version of Opsview to ensure continued support and access to the latest features and security enhancements.
Results Dispatcher
Receives messages (for example, 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/orhost_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
andobject_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 Copied
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 Copied
Refer to Advanced Automated Installation.
Configuration Copied
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 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 files are as follows
/opt/opsview/watchdog/etc/services/opsview-resultsdispatcher.conf
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.
/opt/opsview/watchdog/etc/services/opsview-resultdispatcher.conf
Service administration Copied
As root, start, stop and restart the service using:
/opt/opsview/watchdog/bin/opsview-monit <start|stop|restart> opsview-resultsdispatcher