Configuring Data Pump

Data Pump is configured by using configuration files. One or more configuration files can be specified as operands on the DATAPUMP command. The specified configuration files constitute the configuration when the Data Pump program is started.

The Data Pump configuration specifies where to collect data and what to do with the data. You can collect data from multiple sources. You can manipulate (filter, display, save, and distribute) the collected data. Typically, Data Pump distributes data through a TCP/IP connection to services like InfluxDB and Splunk. The services can be on remote systems or on the same z/VM® system as the virtual machine where Data Pump runs.

Plug-in Types

The configuration defines instances of different types of plug-in modules. The different plug-in types work together to collect, filter, display, save, and distribute performance data. Although a configuration that defines only one plug-in instance is valid, it produces no output. To produce output, a configuration must include at least one plug-in that collects data and at least one plug-in that manipulates the collected data. Data Pump provides the following plug-in types:

MONITOR: The plug-in connects to the *MONITOR system service to collect real-time performance data. The data can be passed to other plug-ins that consume the monitor data.
MONWRITE: The plug-in reads z/VM monitor data that was previously recorded by the CP MONWRITE utility. The data can be passed to other plug-ins that consume the monitor data.
SFS: The plug-in issues a QUERY FILEPOOL command at regular intervals to collect usage information about the storage groups in the specified file pools. When combined with performance data, the SFS usage information can provide more insight about excessive usage and long-term trends.
INFLUXDB: The plug-in formats data according to the InfluxDB Line Write Protocol and sends the data to an InfluxDB instance by using TCP/IP.
SPLUNK: The plug-in uses the Splunk Enterprise HTTP Event Collector (HEC) to send the data to a Splunk service.
STATISTICS: The plug-in reports the volume of data and can help determine the effect of enabling or disabling certain domains or resources. The plug-in can also be used to diagnose other problems in the configuration.
DATADUMP: The plug-in writes CP monitor records to a separate disk file, which can be used for further diagnosis.

Data from the data-collecting plug-ins can be manipulated by the other plug-ins in the following ways:

Table 1. Interaction between data-collecting and other plug-ins
The data from this data-collecting plug-in:	... can be consumed by these data-manipulating plug-ins:
MONITOR	INFLUXDB, SPLUNK, STATISTICS, DATADUMP
MONWRITE	INFLUXDB, STATISTICS, DATADUMP
SFS	INFLUXDB, SPLUNK, STATISTICS

Configuration File Organization

A Data Pump configuration file is composed of one or more sections. Each section defines one instance of one type of plug-in module. A section has the following elements:

Section name

Each section begins with a name, which is a one word label that is enclosed by square brackets ([]). Some error messages include the name of the section that yields the error. Hence, unique section names can help identify the source of a problem.

The section name can use characters that are valid for CMS file names: A-Z, a-z, 0-9, $ (dollar sign), # (number sign), @ (at sign), + (plus sign), - (hyphen), : (colon), and _ (underscore). No blank space is allowed within the label or between the label and the brackets. The section name must be on a line that has no parameters.

The following examples are valid section names:

[influxdb#1]
[Live_Data]

Parameters

Type parameter

Each section contains one TYPE parameter. The TYPE parameter identifies a plug-in type.

The following examples are valid TYPE parameters:

type=monitor
type = influxdb
Type= Splunk

Other parameters

A section can contain other parameters that are appropriate for the plug-in type. Required and optional parameters for each plug-in type are listed in the plug-in topics. See Related Topics.

Comments

Comments are optional. A semicolon indicates a comment. After a semicolon, the remaining data on the line is not processed.

Tips for defining parameters:

The following tips might improve readability and manageability of configuration files:

Indenting parameter lines might improve readability but is not required.
Indent the parameter lines with two spaces so that the first space can easily be changed into a semicolon. Use the first space to “disarm” a parameter temporarily (or to leave the previous setting in the configuration file as documentation).
A value that is a series of tokens can be expressed in portrait form with a trailing comma for continuation. Tokens can be removed by adding a semicolon and added again by removing the semicolon. The following parameter is an example of portrait form.
```
filepool = ,
  gplsrv1 ,
; gplsrv2 , ; Waiting for an admin to enroll the user
  gplsrv3
```

Configuration Requirements

Configurations have the following requirements:

A configuration can contain a single section of TYPE=MONITOR or a single section of TYPE=MONWRITE but not both.
Each section name and each parameter must be on a separate line.
A parameter definition is a key-value pair, which has the format parameter_name=value
When the spaces in a value are significant, enclose the value in double quotation marks.
Configuration files are plain text files in “ini-file format” and must be file type DATAPUMP.

Plug-in topics include requirements that are specific to the plug-in. See Related Topics.

Configuration Notes

The following properties apply to a configuration:

A configuration allows multiple instances (multiple sections) of the following plug-ins: SFS, INFLUXDB, SPLUNK, STATISTICS, DATADUMP.
A data-manipulating plug-in can consume data from more than one data-collecting plug-in.
Some parameters require a boolean value. The case of the value (uppercase or lowercase) is ignored.
- The following boolean values can be used interchangeably: true, yes, on, 1.
- The following boolean values can be used interchangeably: false, no, off, 0.
A parameter definition can span two or more lines if a continuation character is used:
- A comma (,) at the end of a line of data continues a parameter definition on the next line. When the parameter is processed, the lines are joined and the comma is replaced by a space.
- A backslash (/) at the end of a line of data continues a parameter definition on the next line. When the parameter is processed, the lines are joined and the backslash is replaced by no space.
Leading and trailing blank spaces around a section name, a key, or a one-word value are ignored.
The order of sections and the order of parameters within a section does not affect the program.
The configuration file is a flat hierarchy. Sections are not nested.
Casing in section names and parameter names is ignored. Casing might be important for some parameter values that are unique to a user's environment such as user credentials and parts of URLs.
Information from several configuration files can be combined. Specify the configuration files as operands when the DATAPUMP command is issued.

Plug-in topics include notes that are specific to the plug-in. See Related Topics.

Examples

The following configuration content is a minimal example that provides data from the *MONITOR system service to an InfluxDB time-series database:

; z/VM Performance Data Pump Configuration File

[input]
   type = monitor         ; Read data from *MONITOR CP System Service
   
[output_influxdb]
   type = InfluxDB
   url = https://lnxrmh01.pok.ibm.com:8086  ; InfluxDB server and port