Results Forwarder
Receives passive check results from outside of the system and sends them to the appropriate Host or Service checks within Opsview.
Dependencies Copied
The Results-Forwarder requires access to the MessageQueue and Registry. Please make sure these packages are installed, configured and running before attempting to start the results forwarder process.
Installation Copied
Refer to Advanced Automated Installation.
Configuration Copied
The user configuration options should be set in /opt/opsview/resultsforwarder/etc/resultsforwarder.yaml
. Default values are shown in /opt/opsview/resultsforwarder/etc/resultsforwarder.defaults.yaml
, but changes should not be made here since the file will get overwritten on package update.
The following options can be set:
results_fifo
: Location of the results FIFO. Default is/opt/opsview/var/results.sock
.resultssender_queue
: The message-queue configuration to send results.registry
: Connection configuration for the Registry.logging
: Component logging configuration.
Receiving passive results via HTTP Receiver Copied
The HTTP Receiver allows the Results Forwarder to receive passive check results from other systems via HTTP. This can include the following:
- Infrastructure Agents running scheduled plugin executions
- Results Exporters on entirely different Opsview systems for cross-system result forwarding
Unlike the results socket, the HTTP receiver cannot handle acknowledgements.
This configuration can be added alongside other Results Forwarder configuration. It is not enabled by default and must be defined.
resultsforwarder:
...
http_receiver:
enabled: true
host: 0.0.0.0
# Port used can match port previously used for NSCA but does not have to.
# Ensure this port does not clash with any others already used in Opsview.
port: 5667 # For example
allowed_hosts: [] # Follows Infra-Agent conventions for allowed_hosts
user: <username> # Optional user/password combo for basic auth
password: <password> # Optional user/password combo for basic auth
tls_enabled: true
tls:
ca_cert: /opt/opsview/etc/ssl/ca.pem
ca_path: null
cert_file: /opt/opsview/etc/ssl/<host>.openstacklocal.pem
key_file: /opt/opsview/etc/ssl/<host>.openstacklocal.pem
check_client_cert: True
cipher_suite: 'ECDH+AESGCM:ECDH+AES256:ECDH+AES128:!aNULL:!MD5:!DSS'
context_options:
- NO_SSLv3
- NO_TLSv1
- NO_TLSv1_1
Note
The specified port must be open and accessible by the systems sending results, and it should not conflict with any ports already in use by Opsview. Additionally, theallowed_hosts
setting must be configured to accept requests from those systems, which follows the same behavior as described in the Allowed hosts documentation for the Infrastructure Agent.
Once the Results Forwarder is configured to receive passive check results over HTTP, systems can be configured to send data to it.
For more information, refer to Submit passive results in the Infrastructure Agent documentation to configure result forwarding via the Agent. To send data using a Results Exporter, see Configuring a custom output to send data to a Results Forwarder.
Receiving passive results or acknowledgements via results socket Copied
Results and acknowledgements can be submitted into Opsview Monitor by writing into the /opt/opsview/var/results.sock
pipe file found wherever the Results Forwarder is installed.
Entries should be written in the following format:
[<timestamp>] PROCESS_SERVICE_CHECK_RESULT;<host_name>;<service_name>;<return_code>;<plugin_output>
[<timestamp>] PROCESS_HOST_CHECK_RESULT;<host_name>;<return_code>;<plugin_output>
[<timestamp>] ACKNOWLEDGE_HOST_PROBLEM;<host_name>;<sticky>;<notify>;<persistent>;<author>;<comment>
[<timestamp>] ACKNOWLEDGE_SVC_PROBLEM;<host_name>;<service_name>;<sticky>;<notify>;<persistent>;<author>;<comment>
Note
The timestamp should be in epoch format.
For example, to submit a passive result that has just occurred, with a WARNING state (1) and the output text “example text” to a Service “serviceA” on Host “host1”:
echo "[$(date +'%s')] PROCESS_SERVICE_CHECK_RESULT;host1;serviceA;1;example text" >> /opt/opsview/var/results.sock
Unknown hosts or services will be logged into syslog.
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-resultsforwarder.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-resultsforwarder.conf
Service administration Copied
As root, start, stop and restart the service using:
/opt/opsview/watchdog/bin/opsview-monit <start|stop|restart> opsview-resultsforwarder