Splunk® Enterprise

Getting Data In

Download manual as PDF

Download topic as PDF

Assign default fields dynamically

This feature lets you dynamically assign default fields, also known as "metadata", to events as they are being consumed by Splunk software. Use this feature to specify source type, host, or source dynamically for incoming data. This feature is useful mainly with scripted data -- either a scripted input or an existing file processed by a script.

Do not use dynamic metadata assignment with file monitoring (tail) inputs. For more information about file inputs, see Monitor files and directories in this manual.

Note: The modular inputs feature has superseded this ***SPLUNK*** header feature. If you need dynamically-generated values for host, source and sourcetype, consider writing a modular input.

To use this feature, you append a single dynamic input header to your file and specify the metadata fields you want to assign values to. The available metadata fields are sourcetype, host, and source.

You can use this method to assign metadata instead of editing inputs.conf, props.conf, and transforms.conf.

Configure a single input file

To use this feature for an existing input file, edit the file (either manually or with a script) to add a single input header:

      ***SPLUNK*** <metadata field>=<string> <metadata field>=<string> ...

1. Set <metadata field>=<string> to a valid metadata/value pair. You can specify multiple pairs. For example, sourcetype=log4j host=swan.

2. Add the single header anywhere in your file. Any data following the header will be appended with the attributes and values you assign until the end of the file is reached.

3. Add your file to $SPLUNK_HOME/var/spool/splunk or any other directory being monitored by Splunk.

Configure with a script

In the more common scenario, you write a script to dynamically add an input header to your incoming data stream. Your script can also set the header dynamically based on the contents of the input file.

PREVIOUS
About default fields (host, source, sourcetype, and more)
  NEXT
Create custom fields at index time

This documentation applies to the following versions of Splunk® Enterprise: 6.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.0.5, 6.0.6, 6.0.7, 6.0.8, 6.0.9, 6.0.10, 6.0.11, 6.0.12, 6.0.13, 6.0.14, 6.0.15, 6.1, 6.1.1, 6.1.2, 6.1.3, 6.1.4, 6.1.5, 6.1.6, 6.1.7, 6.1.8, 6.1.9, 6.1.10, 6.1.11, 6.1.12, 6.1.13, 6.1.14, 6.2.0, 6.2.1, 6.2.2, 6.2.3, 6.2.4, 6.2.5, 6.2.6, 6.2.7, 6.2.8, 6.2.9, 6.2.10, 6.2.11, 6.2.12, 6.2.13, 6.2.14, 6.2.15, 6.3.0, 6.3.1, 6.3.2, 6.3.3, 6.3.4, 6.3.5, 6.3.6, 6.3.7, 6.3.8, 6.3.9, 6.3.10, 6.3.11, 6.3.12, 6.3.13, 6.3.14, 6.4.0, 6.4.1, 6.4.2, 6.4.5, 6.4.6, 6.4.7, 6.4.8, 6.4.9, 6.4.10, 6.4.11, 6.5.0, 6.5.1, 6.5.1612 (Splunk Cloud only), 6.5.2, 6.5.3, 6.5.4, 6.5.5, 6.5.6, 6.5.7, 6.5.8, 6.5.9, 6.5.10, 6.6.0, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 6.6.7, 6.6.8, 6.6.9, 6.6.10, 6.6.11, 6.6.12, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 7.0.11, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.3.0, 7.3.1, 6.4.3, 6.4.4


Comments

Re (again):

> The modular inputs feature has superseded this ***SPLUNK*** header feature

Do you plan to (a) keep or (b) remove this ***SPLUNK*** header feature in future Splunk releases?

(I wanted to ask this question in my previous comment, but hit the 1000-character limit.)

I'd like to know because I'm considering suggesting to colleagues that we use this feature; your use of the word "superseded" prompts me to check with you.

Perhaps, if you answer (a), and what I am suggesting is true: replace "has superseded" with "offers more flexibility than" (or "is more flexible than")?

Graham Hannington
June 28, 2016

Re:

> The modular inputs feature has superseded this ***SPLUNK*** header

Supersedes, in all cases?

In my case, I use a remote application to send event data to a raw Splunk TCP port. The application sends various source types. Rather than requiring the application to send each source type to a different TCP port, and assign the sourcetype field value per port, I want to retain the flexibility that Splunk offers to assign metadata in other ways: per event via a transform, or per stream via a header. (I can't precisely predict all other use cases of this application or the preferences of other users.)

Writing a modular input to assign metadata field values seems like more work than inserting a header, or even writing a regex-based transform (although I've already hit the limit of those C-library PCRE transforms due to the lack of case conversion). Especially when my app can easily insert that header line. IdeaIly, a function that supersedes another should make the same task easier.

Graham Hannington
June 27, 2016

Was this documentation topic helpful?

Enter your email address, and someone from the documentation team will respond to you:

Please provide your comments here. Ask a question or make a suggestion.

You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters