ITRS Opsview Cloud Documentation

Withdraw of the 6.9.2 Release

Unfortunately, due to critical issues identified with version 6.9.2, we have decided to remove it and ensure it's no longer available for download. These issues impacted the ability to install or upgrade but none were security-related. We are diligently working to resolve these issues and are planning to release an updated version 6.9.3 in early May.

What if you've already upgraded?

For customers who have already upgraded to 6.9.2, no immediate action is required, as none of these issues are security-related. Once it's available, you will still be able to upgrade to 6.9.3 as normal. We appreciate your patience and trust as we continue to enhance our software to better serve you. Thank you for your understanding.

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:

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>


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


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.


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?