Getting Data In

Issue with overriding per-event custom sourcetypes while getting data from universal forwarder

splnktester
New Member

Hello!
I have issue while getting my application logs data from universal forwarder working in my network.

My configs on indexer server:

1) props.conf

[Planet3_Application_Logs]

TRANSFORMS-001 = planet3_app_logs

BREAK_ONLY_BEFORE = event id

NO_BINARY_CHECK = 1

SHOULD_LINEMERGE = true

TIME_PREFIX = date

TZ = Europe/Samara

pulldown_type = 1

2) transforms.conf

[planet3_app_logs]

REGEX = event id

FORMAT = sourcetype::Planet3_Application_Logs

DEST_KEY = MetaData:Sourcetype

So, i used this manual

http://docs.splunk.com/Documentation/Splunk/latest/Data/Advancedsourcetypeoverrides

And as result i see, that all my logs are coming in FROM UNIVERSAL forwarder in automate assigned xml sourcetypes by splunk indexer. However, local data inputs in my custom sourcetypes work fine

What's the problem?

0 Karma

splnktester
New Member

UP question!

0 Karma

splnktester
New Member

Yes. I'm sure

0 Karma

Ayn
Legend

Just to make sure - you're confident in that this forwarder you're sending from IS a Universal Forwarder and not some other kind of heavy forwarder?

0 Karma
Got questions? Get answers!

Join the Splunk Community Slack to learn, troubleshoot, and make connections with fellow Splunk practitioners in real time!

Meet up IRL or virtually!

Join Splunk User Groups to connect and learn in-person by region or remotely by topic or industry.

Get Updates on the Splunk Community!

Splunk App Dev Quarterly Roundup: AI, Agents, and Innovation!

Another quarter, another wave of innovation. From complex integrations to pushing the limits ...

Federated Search for Dynamic Data Self Storage Is Now Generally Available on Splunk ...

 Splunk is excited to announce the General Availability of Federated Search for Dynamic Data Self Storage ...

Index This | What has many keys but can’t unlock a door?

July 2026 Edition  Hayyy Splunk Education Enthusiasts and the Eternally Curious!   We’re back with this ...