--- title: "Results Forwarder" description: "" url: "https://docs.itrsgroup.com/docs/opsview/6.12.6/administration/distributing-functionality/results-forwarder/index.html" --- Receives [passive check results](https://docs.itrsgroup.com/docs/opsview/6.12.6/configuration/service-checks-and-host/passive-checks/index.html#what-are-passive-checks) from outside of the system and sends them to the appropriate Host or Service checks within Opsview. ## Dependencies 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 Refer to [Advanced Automated Installation](https://docs.itrsgroup.com/docs/opsview/6.12.6/install/advanced-installation/index.html). ## Configuration 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 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](#receiving-passive-results-or-acknowledgements-via-results-socket), the HTTP receiver cannot handle acknowledgements. This configuration can be added alongside other [Results Forwarder configuration](#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: # Optional user/password combo for basic auth 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/.openstacklocal.pem key_file: /opt/opsview/etc/ssl/.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](https://docs.itrsgroup.com/docs/infrastructure-agent/current/prerequisites/prerequisites/index.html#ports) already in use by Opsview. Additionally, the `allowed_hosts` setting must be configured to accept requests from those systems, which follows the same behavior as described in the [Allowed hosts](https://docs.itrsgroup.com/docs/infrastructure-agent/current/install/installation-and-operation/index.html#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](https://docs.itrsgroup.com/docs/infrastructure-agent/current/configure/submit-passive-results/index.html) 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](https://docs.itrsgroup.com/docs/opsview/6.12.6/administration/exporting-results/index.html#configuring-a-custom-output-to-send-data-to-a-results-forwarder). ## Receiving passive results or acknowledgements via results socket 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: ``` [] PROCESS_SERVICE_CHECK_RESULT;;;; [] PROCESS_HOST_CHECK_RESULT;;; [] ACKNOWLEDGE_HOST_PROBLEM;;;;;; [] ACKNOWLEDGE_SVC_PROBLEM;;;;;;; ``` **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 ### 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-resultsforwarder.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-resultsforwarder.conf ``` ### Service administration As root, start, stop and restart the service using: ``` /opt/opsview/watchdog/bin/opsview-monit opsview-resultsforwarder ```