Getting Data In

How to route to an Index based on SourceType AND Host combination in inputs.conf?

Explorer

I have a setup as Universal Forwarder (UF) - Heavy Forwarder (HF) - Indexer - Search Head (SH).
Where multiple UF are sending data to single HF which in turn sends data to single Indexer.

I have below stanza on my multiple UF's inputs.conf file

[perfmon://CPU Load]
counters = % Processor Time;% User Time
object = Processor
instances = _Total
interval = 30
sourcetype = Perfmon
index = idx_XXX_Perfmon_CPU-Load

Where XXX is server name. Now, in order to have a common app across all UF to be deployed through Deployment server, I have removed the Index from the stanza and wants to assign index based on Host + SourceType combination on a HF using props.conf and transform.conf.

Example:
- If event comes from Server1 with sourcetype as Perfmon then set index = idx_Server1_Perfmon_CPU-Load
- If event comes from Server2 with sourcetype as Perfmon then set index = idx_Server2_Perfmon_CPU-Load.

Please help me to design correct stanza for this requirement.

0 Karma
1 Solution

Splunk Employee
Splunk Employee

Splunk can route events to a specific index based on the server name. Below is a snippet of props.conf as well as the transforms.conf stanza that will perform the index routing that you described. Check https://docs.splunk.com/Documentation/Splunk/6.5.1/Admin/Transformsconf for details on the attributes used in the transform.conf stanza.

Props.conf (snippet)

description = Index is overwritten by the transforms
TRANSFORMS-setindex=setindexbyhost

Transforms.conf

[setindexbyhost]
SOURCE_KEY = MetaData:Host
REGEX = ^host::(.*)$
DEST_KEY = MetaData:Index
FORMAT = idx
_$1_perfmon_cpu-load

However, having a separate index for each source server is not recommended. This could lead to both management and performance challenges in a large Splunk installation. There are definitely cases where one may want to split out events for a group of source servers due to thing such as access and/or retention requirements. For example, send all development server events to a development index and all production server events to production index.

View solution in original post

0 Karma

Splunk Employee
Splunk Employee

Splunk can route events to a specific index based on the server name. Below is a snippet of props.conf as well as the transforms.conf stanza that will perform the index routing that you described. Check https://docs.splunk.com/Documentation/Splunk/6.5.1/Admin/Transformsconf for details on the attributes used in the transform.conf stanza.

Props.conf (snippet)

description = Index is overwritten by the transforms
TRANSFORMS-setindex=setindexbyhost

Transforms.conf

[setindexbyhost]
SOURCE_KEY = MetaData:Host
REGEX = ^host::(.*)$
DEST_KEY = MetaData:Index
FORMAT = idx
_$1_perfmon_cpu-load

However, having a separate index for each source server is not recommended. This could lead to both management and performance challenges in a large Splunk installation. There are definitely cases where one may want to split out events for a group of source servers due to thing such as access and/or retention requirements. For example, send all development server events to a development index and all production server events to production index.

View solution in original post

0 Karma

Champion

I am pretty sure there are plenty of people that have accomplished deploying common UF apps without separating indexes by server. In fact, a large deployment built this way will likely encounter some problems or at least become difficult to manage given the potential number of indexes.

My question would be why do you want to separate indexes by server? Is there some requirement that demands this?

0 Karma

Explorer

The primary reason for having separate index by server is to get rid of unwanted data easily once the server from lab environment is decommissioned. If I have a common index across host, how easy is to delete unwanted events from index.
Having a separate index per server is not recommended?

0 Karma

SplunkTrust
SplunkTrust

Having an index per server is not recommended, that would be far too many indexes.
To handle the above situation why don't you use the deployment server to publish multiple applications with different index configurations for different servers?

in my scenario I'm publishing the main configuration in 1 app and additional more specific configuration in another application.
For example I publish a generic Windows TA application, then a publish an additional application with the performance monitoring enabled for the servers that require it...