Configure forwarders with outputs.conf
This documentation does not apply to the most recent version of Splunk. Click here for the latest version.
Configure forwarders with outputs.conf
The outputs.conf file is unique to forwarders. It defines how forwarders send data to receivers. You can specify some output configurations at installation time (universal forwarders only) or through Splunk Web (heavy/light forwarders only) or the CLI, but most advanced configuration settings require that you directly edit
outputs.conf. The topics describing various topologies, such as load balancing and data routing, provide detailed examples on configuring
outputs.conf to support those topologies.
outputs.conf is a critical file for configuring forwarders, it specifically addresses the outputs from the forwarder. To specify the inputs to a forwarder, you must separately configure the inputs, as you would for any Splunk instance. For details on configuring inputs, see "Add data and configure inputs" in the Getting Data In manual.
Create and modify outputs.conf
A single forwarder can have multiple
outputs.conf files (for instance, one located in an apps directory and another in
/system/local). No matter how many
outputs.conf files the forwarder has and where they reside, the forwarder combines all their settings, using the rules of location precedence, as described in "Configuration file precedence". For purposes of distribution and management simplicity, you might prefer to maintain just a single
The default location of the
outputs.conf file depends on the type of forwarder:
- The universal forwarder on *nix systems. It does not come with a
outputs.conffile. When you use the CLI to configure the forwarder's outputs, Splunk creates
$SPLUNK_HOME/etc/system/local/. You can edit that file directly as well.
- The universal forwarder on Windows systems. The Windows installation process writes configuration changes to an
outputs.conffile located in the MSICreated app.
For more information on configuring the universal forwarder, look here.
- Heavy and light forwarders. These do not ship with a default
outputs.conffile. When you enable a heavy/light forwarder through Splunk Web or the CLI, Splunk creates an
outputs.conffile in the directory of the currently running app. For example, if you're working in the search app, Splunk places the file in
$SPLUNK_HOME/etc/apps/search/local/. You can then edit it there. To enable and configure a heavy/light forwarder without using Splunk Web or the CLI, create an
outputs.conffile in this directory:
After making changes to
outputs.conf, you must restart the forwarder for the changes to take effect.
For detailed information on
outputs.conf, look here for the spec and examples.
There are two types of output processors: tcpout and syslog. (Note: The syslog processor is not available for universal or light forwarders.)
You configure the output processors at three levels of stanzas:
- Global. At the global level, you specify any attributes that you want to apply globally, as well as certain attributes only configurable at the system-wide level for the output processor. This stanza is optional.
- Target group. A target group defines settings for one or more receiving indexers. There can be multiple target groups per output processor. Most configuration settings can be specified at the target group level.
- Single server. You can specify configuration values for single servers (receivers) within a target group. This stanza type is optional.
Configurations at the more specific level take precedence. For example, if you specify
compressed=true for a single receiver, the forwarder will send that receiver compressed data, even if
compressed is set to "false" for the receiver's target group.
Note: This discussion focuses on the tcpout processor, which uses the
[tcpout] header. For the syslog output processor, see "Forward data to third-party systems" for details.
Here you set any attributes that you want to apply globally. There are also two attributes that you can set only at the global level:
The global stanza for the tcpout procesor is specified with the
Here's an example of a global tcpout stanza:
[tcpout] defaultGroup=indexer1 indexAndForward=true
This global stanza includes two attribute/value pairs:
- defaultGroup=indexer1 This tells the forwarder to send all data to the "indexer1" target group. See "Default target groups" for more information.
- indexAndForward=true This tells the forwarder to index the data locally, as well as forward the data to receiving indexers in the target groups. If set to "false" (the default), the forwarder just forwards data but does not index it. This attribute is only available for heavy forwarders; universal and light forwarders cannot index data.
Note: Beginning with the 4.2 release, the global stanza is no longer required. However, if you want to set the
defaultGroup attribute or any other attribute settable only at the global level, you still need that stanza.
Target group stanza
The target group identifies a set of receivers. It also specifies how the forwarder sends data to those receivers. You can define multiple target groups.
Here's the basic pattern for the target group stanza:
[<output_processor>:<target_group>] server=<receiving_server1>, <receiving_server2>, ... <attribute1> = <val1> <attribute2> = <val2> ...
<output_processor>, you can specify tcpout or syslog.
To specify a receiving server in a target group, use the format
<port> is the receiving server's listening port. For example,
myhost.Splunk.com:9997. You can specify multiple receivers and the forwarder will load balance among them.
See "Define typical deployment topologies", later in this topic, for information on how to use the target group stanza to define several deployment topologies.
You can define a specific configuration for an individual receiving indexer. However, the receiver must also be a member of a target group.
When you define an attribute at the single-server level, it takes precedence over any definition at the target group or global level.
Here is the syntax for defining a single-server stanza:
[tcpout-server://<ipaddress_or_servername>:<port>] <attribute1> = <val1> <attribute2> = <val2> ...
outputs.conf example contains three stanzas for sending tcpout to Splunk receivers:
- Global settings. In this example, there is one setting, to specify a defaultGroup.
- Settings for a single target group consisting of two receivers. Here, we are stipulating that the forwarder send the data in compressed form to the targeted receivers. It load balances between them.
- Settings for one receiver within the target group. This stanza turns off compression for this particular receiver. The server-specific value for "compressed" takes precedence over the value set at the target group level.
[tcpout] defaultGroup=my_indexers [tcpout:my_indexers] compressed=true server=mysplunk_indexer1:9997, mysplunk_indexer2:9996 [tcpout-server://mysplunk_indexer1:9997] compressed=false
Default target groups
To set default groups for automatic forwarding, include the
defaultGroup attribute at the global level, in your
[tcpout] defaultGroup= <target_group1>, <target_group2>, ...
The defaultGroup specifies one or more target groups, defined later in
tcpout:<target_group> stanzas. The forwarder will send all events to the specified groups.
If you do not want to forward data automatically, don't set the
defaultGroup attribute. (Prior to 4.2, you were required to set the
defaultGroup to some value. This is no longer necessary.)
For some examples of using the
defaultGroup attribute, see "Route and filter data".
Define typical deployment topologies
This section shows how you can configure a forwarder to support several typical deployment topologies. See the other topics in the "Forward data" section of this book for information on configuring forwarders for other topologies.
To perform load balancing, specify one target group with multiple receivers. In this example, the target group consists of three receivers:
The forwarder will load balance between the three receivers listed. If one receiver goes down, the forwarder automatically switches to the next one available.
To perform data cloning, specify multiple target groups, each in its own stanza. In data cloning, the forwarder sends copies of all its events to the receivers in two or more target groups. Data cloning usually results in similar, but not necessarily exact, copies of data on the receiving indexers. Here's an example of how you set up data cloning:
[tcpout] defaultGroup=indexer1,indexer2 [tcpout:indexer1] server=10.1.1.197:9997 [tcpout:indexer2] server=10.1.1.200:9997
The forwarder will send duplicate data streams to the servers specified in both the
indexer2 target groups.
Data cloning with load balancing
You can combine load balancing with data cloning. For example:
[tcpout] defaultGroup=cloned_group1,cloned_group2 [tcpout:cloned_group1] server=10.10.10.1:9997, 10.10.10.2:9997, 10.10.10.3:9997 [tcpout:cloned_group2] server=10.1.1.197:9997, 10.1.1.198:9997, 10.1.1.199:9997, 10.1.1.200:9997
The forwarder will send full data streams to both
cloned_group2. The data will be load-balanced within each group, rotating among receivers every 30 seconds (the default frequency).
Note: For syslog and other output types, you must explicitly specify routing as described here: "Route and filter data".
outputs.conf file provides a large number of configuration options that offer considerable control and flexibility in forwarding. Of the attributes available, several are of particular interest:
|defaultGroup||n/a||global stanza||A comma-separated list of one or more target groups. Forwarder sends all events to all specified target groups. Don't set this attribute if you don't want events automatically forwarded to a target group.|
|indexAndForward||false||global stanza||If set to "true", the forwarder will index all data locally, in addition to forwarding the data to a receiving indexer.
Important: This attribute is only available for heavy forwarders. A universal forwarder cannot index locally.
|server||n/a||target group stanza|| Required. Specifies the server(s) that will function as receivers for the forwarder. This must be set to a value using the format |
|disabled||false||any stanza level||Specifies whether the stanza is disabled. If set to "true", it is equivalent to the stanza not being there.|
|sendCookedData||true||any stanza level||Specifies whether data is cooked before forwarding.|
|compressed||false||any stanza level||Specifies whether the forwarder sends compressed data.|
|ssl....||n/a||any stanza level||Set of attributes for configuring SSL. See "Use SSL to encrypt and authenticate data from forwarders" in the Admin manual for information on how to use these attributes.|
|useACK||false||global or target group stanza||Specifies whether the forwarder waits for indexer acknowledgment confirming that the data has been written to the file system. See "Protect against loss of in-flight data".|
outputs.conf.spec file, which you can find here, along with several examples, provides details for these and all other configuration options. In addition, most of these settings are discussed in topics dealing with specific forwarding scenarios.
Note: In 4.2, the persistent queue capability has been much improved. It is now a feature of data inputs and is therefore configured in inputs.conf. It is not related in any way to the previous, deprecated persistent queue capability, which was configured through
outputs.conf. See "Use persistent queues to prevent data loss" for details.