Results Forwarder

Receives Passive results from outside of the system in 4k Blocks from a separately installed source, such as NRD or NSCA.

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:

Receiving passive results via HTTP Receiver Copied

The HTTP Receiver allows the Results Forwarder to receive passive check results from other parts of the Opsview system. This includes the following:

This configuration can be added in opsview-deploy alongside the Results Exporter configuration. It is not enabled by default and must be defined.

resultsforwarder:
  ...
  http_receiver:
    enabled: true
    host: 0.0.0.0
    port: 5667  # NSCA port
    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

For more information, see Submit passive results in the Infrastructure Agent documentation. To configure Results Exporter to send data to the HTTP Receiver in Results Forwarder, see Exporting results.

Submitting results Copied

Results and acknowledgements can be submitted into Opsview Monitor by writing into the /opt/opsview/var/results.sock pipe file. This can be used for submitting passive checks.

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
["Opsview On-Premises"] ["User Guide"]

Was this topic helpful?