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 Exporter

Opsview Results Exporter exports results to services such as Splunk, syslog, local files, and arbitrary HTTP endpoints.

Known issue

When logging data to Rsyslog via TCP, the first message has the correct priority, but all subsequent messages use the user.notice priority.

Installation Copied

Like other Opsview components, the Results Exporter is installed and managed via Opsview Deploy. It can be installed on the Orchestrator system or any infrastructure systems making up part of the Orchestrator (not in a Cluster).

The installation of Results Exporter is controlled by the opsview_module_results_exporter Opsview Deploy variable. By default, it is set to False. To enable it, set opsview_module_results_exporter to True in /opt/opsview/deploy/etc/user_results_exporter.yml.

If you are coming from an older version of Opsview Monitor, you may be missing user_results_exporter.yml. To get a copy of this in the correct location, run the following in a shell on the box with Opsview Deploy:

cp -n /opt/opsview/deploy/etc/examples/user_results_exporter-example.yml /opt/opsview/deploy/etc/user_results_exporter.yml

Configuration Copied

The opsview-results-exporter component is configurable via the user_results_exporter.yml file under /opt/opsview/deploy/etc/.


Ensure that your component configuration has the correct Message Queue encoder key, password, database password, and registry password during installation. These values were generated when you deployed Opsview and can be found in /opt/opsview/deploy/etc/user_secrets.yml.

For instructions on how to add your own outputs, please refer to the examples described in Exporting Results.

Migration from manually installed Results Exporter Copied

The automated installation and configuration of the Opsview Results Exporter has been added to Opsview Deploy. Previously, the component and its configuration files had to be installed manually.

By running the check_deploy playbook on an environment that has a manually installed Results Exporter, Opsview Deploy will inform you that it will back up any existing Results Exporter configuration and then overwrite it with the configuration in the user_results_exporter file.

To continue using the existing Results Exporter configuration, the customized fields in /opt/opsview/resultsexporter/etc/resultsexporter.yaml must be carried across to user_results_exporter.yml. To get a copy of this in the correct location, run the following in a shell on the box with Opsview Deploy:

cp -n /opt/opsview/deploy/etc/examples/user_results_exporter-example.yml /opt/opsview/deploy/etc/user_results_exporter.yml

By default, the installation of the Deploy Managed exporter is disabled. To enable it, set the opsview_module_results_exporter to True in the user_results_exporter.yml file.

The following table shows which old fields from the resultsexporter.yaml file map to new fields in the user_results_exporter.yml file. The Message Queue, Database, and Registry configuration do not need to be copied over, as they are managed solely by Opsview Deploy.

resultsexporter.yml field user_results_exporter.yml field
worker_timeout opsview_results_exporter_worker_timeout
initial_worker_count opsview_results_exporter_initial_worker_count
default_filter opsview_results_exporter_default_filter
default_fields opsview_results_exporter_default_fields
data_access_cache opsview_results_exporter_data_access_cache
outputs opsview_results_exporter_outputs

For example, the following excerpt from the resultsexporter.yml file:

        - hostname
        - stdout
        - perf_data_raw

This would be rewritten as follows and placed in the user_results_exporter.yml file to continue using it:

        - hostname
        - stdout
        - perf_data_raw

Advanced Configuration Copied

Worker settings Copied

The number of parallel component workers and the timeout before component worker restart (if encountering errors) can be set as follows:

opsview_results_exporter_worker_timeout: <secs>       # default 30
opsview_results_exporter_initial_worker_count: <num>  # default to 0, which will spawn as many workers as the machines CPU has logical processors

Please note the following considerations:

Data cache settings Copied

The Results Exporter can cache Opsview data if the dal_fetchall or dal_fetchone field operations are in use. For more information, see Exporting Results.

You can override the opsview_results_exporter_data_access_cache section in the user_results_exporter file to have full control over the cache settings:

  - <data model type>:        # e.g. RuntimeHosts
      cache_items: <yes|no>   # whether to cache data for the model
      max_items: <num>        # if caching, the maximum number of items to cache (if field unset, defaults to no limit)
      max_item_size: <num>    # if caching, the maximum size of any cached item (if field unset, defaults to no limit)
      pre_load: <yes|no>      # whether to pre-load data on component start up (default no)
      refresh_on: reload      # set if the cache should be cleared for the model when Apply Changes completes

Please note the following considerations:

By default, the component uses the following cache configuration:

  - RuntimeHashtags:
      cache_items: no
  - RuntimeHosts:
      cache_items: yes
      max_items: 8_000
      max_item_size: 1
      pre_load: yes
      refresh_on: reload
  - RuntimeServicechecks:
      cache_items: yes
      max_items: 32_000
      max_item_size: 1
      pre_load: yes
      refresh_on: reload

The component will generate a warning if it encounters an unexpected model type.

Data from unsupported model ... could not be queried from cache

If intentionally not caching a model type, then add a cache_items: no entry for the model to the cache settings to suppress the logging. This will require overriding the entire section and then adding your new entries.

Logging Settings Copied

The Results Exporter logging settings can be set by overriding the following section:

    sensitive_trace: <yes|no>   # enable low-level trace logging (default no)
      collisions: <yes|no>      # whether to log data cache collisions (default no)
        level: NOTICE           # overall component log level

The sensitive_trace will only have an effect if the component is also set at the DEBUG log level.

Service administration Copied

As root, start, stop and restart the service using:

/opt/opsview/watchdog/bin/opsview-monit <start|stop|restart> opsview-resultsexporter
["Opsview On-premises"] ["User Guide"]

Was this topic helpful?