Related Answers
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.3, 6.4.4, 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.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6
Comments
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.
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")?