Deployment Architecture

parsing on Universal Forwarder

gcusello
SplunkTrust
SplunkTrust

Hi at all,
I found a strange behavior of my Splunk instance or maybe it's only my low Splunk knowledge!.
I have a Universal Forwarder that sends many kinds of log to an indexer and it correctly works since many months.
Now I added a new CSV based log in the UF configuring also the props.conf in the Indexer, but I found that it isn't well indexed: wrong timestamp, no field extraction, ...
props.conf is correct infact manually loading the same log, it's well indexed.
After many tests I found that copying the app's props.conf from the Indexer to the Universal Forwarder my log is correctly indexed.
I knew that the parse phase is usually done in the Indexer and not in the UF, but this experience seems to say that this is not always correct.
Someone can explain if there are exceptions to the normal Splunk indexing?
Thank you in advance.
Bye.
Giuseppe

0 Karma
1 Solution

Jeremiah
Motivator

The key here is that you are using INDEXED_EXTRACTIONS. Sourcetypes that use INDEXED_EXTRACTIONS need to have their props.conf on the universal forwarder. There is a good explanation as to the "why" here:

https://answers.splunk.com/answers/268335/why-is-the-sourcetype-specified-in-inputsconf-on-t.html

There are some default sourcetypes already setup in your UF's etc/system/default/props.conf, but if you want to do any customization of those sourcetypes, or create your own using INDEXED_EXTRACTIONS, you'll need to put the props settings on your universal forwarder. You should also make sure to disable KV_MODE on your searchhead too for any of these sourcetypes, or you can end up with both search time and index time extractions (you'll see two fields instead of one). This is usually more of a problem for json than for csv data.

Lots of Q&A about indexed extractions here:
https://answers.splunk.com/topics/indexed_extractions.html

View solution in original post

0 Karma

Jeremiah
Motivator

The key here is that you are using INDEXED_EXTRACTIONS. Sourcetypes that use INDEXED_EXTRACTIONS need to have their props.conf on the universal forwarder. There is a good explanation as to the "why" here:

https://answers.splunk.com/answers/268335/why-is-the-sourcetype-specified-in-inputsconf-on-t.html

There are some default sourcetypes already setup in your UF's etc/system/default/props.conf, but if you want to do any customization of those sourcetypes, or create your own using INDEXED_EXTRACTIONS, you'll need to put the props settings on your universal forwarder. You should also make sure to disable KV_MODE on your searchhead too for any of these sourcetypes, or you can end up with both search time and index time extractions (you'll see two fields instead of one). This is usually more of a problem for json than for csv data.

Lots of Q&A about indexed extractions here:
https://answers.splunk.com/topics/indexed_extractions.html

0 Karma

Raschko
Communicator

Can you post the stanza for the props.conf?

0 Karma

gcusello
SplunkTrust
SplunkTrust

[mylog]
DATETIME_CONFIG =
FIELD_DELIMITER = |
INDEXED_EXTRACTIONS = csv
KV_MODE = none
NO_BINARY_CHECK = true
SHOULD_LINEMERGE = false
category = Structured
description = Comma-separated value format. Set header and other settings in "Delimited Settings"
disabled = false
pulldown_type = true
TIMESTAMP_FIELDS = EVENT_TIME
TIME_FORMAT = %d/%m/%Y %H:%M:%S
HEADER_FIELD_LINE_NUMBER = 1

Thank you.
Giuseppe

0 Karma
Get Updates on the Splunk Community!

Extending Observability Content to Splunk Cloud

Watch Now!   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to leverage ...

More Control Over Your Monitoring Costs with Archived Metrics!

What if there was a way you could keep all the metrics data you need while saving on storage costs?This is now ...

New in Observability Cloud - Explicit Bucket Histograms

Splunk introduces native support for histograms as a metric data type within Observability Cloud with Explicit ...