## Overview

Easily and securely export high volumes of event data in real time to Splunk and other SIEM/analytics platforms

Highly-scalable Opsview Monitor is a solution for monitoring, aggregating, visualizing, alerting on, and drilling into event data from across arbitrarily-large, complex, multi-location, premise- and cloud-based enterprise IT estates. Enough so that it can be the "single pane of glass" that IT operations needs to work efficiently.

Opsview Monitor can also work as a take-off point -- providing data to other analytics, Security Information and Event Management (SIEM), bulk storage and other systems. The Opsview Monitor Results Exporter provides a complete, easy-to-use toolkit for extracting, filtering, and reformatting raw data directly from Opsview Monitor's message queue, and forwarding it to Splunk (SaaS or local) analytics, Enterprise Security, or to a host of other SIEM platform via syslog or HTTP.

## Getting Started

To use the Results Exporter, you first need to [Install the Results Exporter Component](🔗) and then configure an output.

Currently supported outputs and information on how to configure them:

• [Syslog Outputs](🔗) - send information to a local or remote syslog server

• [File Outputs](🔗) - send information to a file on the local filesystem

• [HTTP Outputs](🔗) - send information over HTTP to a remote server - includes predefined supported types:

  • [Splunk Event Collector](🔗) - over unverified SSL.

  • [Certified Splunk Event Collector](🔗) - over verified SSL.

## Syslog Output

Results can be exported to a local or remote syslog server by configuring a syslog output, under the outputs section of your configuration file `/opt/opsview/resultsexporter/etc/resultsexporter.yaml`, e.g:

### Configuring a Syslog Output

The following options may be specified for your syslog output:

#### Required

None - if declared with no options, will log to `/dev/log` with all default settings.

#### Options

#### Log Date Format Strings

#### Log Format Strings

## File Outputs

Results can be exported to a file on the local system by configuring a file output, under the outputs section of your configuration file `/opt/opsview/resultsexporter/etc/resultsexporter.yaml`, e.g:

### Configuring a File Output

The following options can be specified for your file output:

#### Required

#### Optional

## HTTP Outputs

Results can be exported via HTTP to an external service by configuring a HTTP output, under the outputs section of your configuration file `/opt/opsview/resultsexporter/etc/resultsexporter.yaml`, e.g:

### Configuring a Custom HTTP Output

#### Required

#### Optional

### Configuring a Predefined HTTP Output

The following options can be specified for an HTTP output with a predefined `type`: spunk, splunk-cert

#### splunk

Results can be exported via unverified HTTPS to Splunk by configuring a HTTP output with `type: splunk` under the http section of your configuration file outputs within `/opt/opsview/resultsexporter/etc/resultsexporter.yaml`, e.g:

The following parameters are required for an HTTP Splunk output:

#### splunk-cert

Results can be exported via HTTPS to Splunk (using a client certificate) by configuring a HTTP output with type splunk-cert under the http section of your configuration file outputs within `/opt/opsview/resultsexporter/etc/resultsexporter.yaml`, e.g:

The following parameters are required for an HTTP Splunk output:

Note: If your client certificate and key are both within the same `.pem` file then you can simply list that file path for both `certfile` and `keyfile`.

## Field Mapping

The Results Exporter allows you to transform the messages as they are exported, by specifying exactly which message fields should be present in the exported result, so you can remove details from the messages you do not want or need:

Within `/opt/opsview/resultsexporter/etc/resultsexporter.yaml`:

### Specifying Fields

The fields of messages being exported are fully configurable. To select the fields that should be included in exported messages, list the keys under the fields section of an output. For example to include the `hostname`, `servicecheckname`, `current_state` and `stdout` fields, add them to the fields section:

##### Simple Examples

#### Mapping and renaming fields

Users can also specify custom keys which are given values based on a mapping. For example to retrieve the `host_state` as a new field with name `host_state_string`, and value `UP` or `DOWN` instead of `0` or `1`:

In this example, the value of `host_state` determines behaviour as below:

A default value can also be specified. For example, in the example below, if the value of the `hostname` field does not match 'web-server' or 'email-server' , the value will be set to 'AllCompany'. If a default value is not specified and the key does not match any of the keys provided, the field will be omitted from the output.

This example results in behaviour as below:

Fields can also be added where the value is always constant.

This example results in behaviour as below:

Mapped values can refer to any (original) message fields, by using the format syntax: `%(<field>)s`, as shown in the example below.

This example results in behaviour as below:

This allows message fields to be 'renamed' easily if required by providing a one to one mapping with the original message field. For example to 'rename' the `hostname` field to `name`:

This example results in behaviour as below:

🚧



Note: if you change your mapping values then you should review all your filters to ensure they will still work as expected

##### Reusing fields

To avoid duplication, the fields can be defined once using the `&` (yaml anchor) operator and reused multiple times using the `*` (anchor reference) operator.

Alternatively, anchors can be declared as a list, and can have optional names for clarity, as in this example:

#### Performance Data Fields

The Results Exporter component exposes the individual metrics within the performance data of each message. To include the raw performance data string in your exported message, include the `perf_data_raw` field within your list of fields e.g for a service check with performance data of:

To include the entire performance data as a nested structure within your message, include the `perf_data` field:

To include some of the nested fields, but not all, you can specify specific named metrics as below:

### Supported fields

## Filtering

A powerful feature of the Results Exporter is the ability to select exactly which messages you want to be exported via each output, using a filter string. Any message that meets the condition specified in the filter will be processed and exported by that output e.g:

### Specifying Filters

Using a filter allows you to focus on exporting the results that are important and ignore anything that isn't relevant to your chosen reporting/searching tool.

### Inbuilt Filters

A filter string can also consist of a comparison between a key within the message and a value (the value for the key within each message being filtered).

More complex filters can be written by combining filter strings using the `&&` (logical and) and `||` (logical or) operators.

#### Supported comparisons

### Supported Fields

Within your filter, you can refer to any field listed as supported in Field Mapping, with the exception of `perf_data`, `perf_data_raw` and any extracted performance data fields. These are not supported by the filter.

##### Simple Filter Examples

##### Complex Filter Examples

NOTE: It is advised to surround your filters with single quotes:

If your filter is surrounded in double quotes, you will need to escape backlashes in your regular expressions:

#### Reusing Filters

To avoid duplication, the filters can be defined once using the `&` (yaml anchor) operator and reused multiple times using the `*` (anchor reference) operator.

Alternatively, anchors can be declared as a list, and can have optional names for clarity, as in this example:

#### Multi-line Filters

Multi-line filters are possible as long as the entire filter is quoted - this can add clarity for complex filters as seen below:

## Formatting Messages

The Results Exporter allows you to declare the format type of the exported messages for file and HTTP outputs, as well as adding any additional information to each message using a format string:

### Format Types

The list of currently supported format types is as follows:

• XML

• JSON

• KVP (Key Value Pairs)

• YAML

### Example Job Result Message:

#### Formatted into kvp:

#### Formatted into json:

#### Formatted into xml:

#### Formatted into yaml: