Getting Data In

Changing pre-trained sourcetype to custom sourcetype names.

Communicator

I have been receiving numerous requests from my consumers on having their WinEventLog: sourcetypes changed to a custom sourcetype name.

My question is this: What complications does this invite into my environment? I have heard on numerous forums that this is not a best practice and quite honestly not something that I am wanting to manage, but I want to speak my concerns with factual information when addressing my customers.

Are there better ways for them to organize their environment without affecting changes to pre-trained sourcetypes: Tags? Lookups?
Any advice and guidance as always is very much appreciated.

0 Karma
1 Solution

Ultra Champion

I agree that changing the sourcetype isn't fun because of the other apps and add ons that might assume the sourcetype name for some of those common ones like Windows.
I think you're on the right track by trying to understand why they want to do that and what challenge they are trying to address with that solution.
For example, using eventtypes and tags may be perfect for helping them find "their" events more easily. Then you can use a naming convention for eventtypes and tags so teams can easily wildcard to find their data. For example, I might define tags for my web, app, and db data as 'burch_web', 'burch_app', and 'burch_db'. I can then easily find my data amongst the larger set of the same sourcetypes with search terms like 'tag=burch_*'. In other words, with tags and eventtypes, they can use the benefits of the sourcetype but then easily fetch their sources that might be a subset of that sourcetype.

View solution in original post

Ultra Champion

I agree that changing the sourcetype isn't fun because of the other apps and add ons that might assume the sourcetype name for some of those common ones like Windows.
I think you're on the right track by trying to understand why they want to do that and what challenge they are trying to address with that solution.
For example, using eventtypes and tags may be perfect for helping them find "their" events more easily. Then you can use a naming convention for eventtypes and tags so teams can easily wildcard to find their data. For example, I might define tags for my web, app, and db data as 'burch_web', 'burch_app', and 'burch_db'. I can then easily find my data amongst the larger set of the same sourcetypes with search terms like 'tag=burch_*'. In other words, with tags and eventtypes, they can use the benefits of the sourcetype but then easily fetch their sources that might be a subset of that sourcetype.

View solution in original post

Ultra Champion

Regarding sourcetype renaming, it is this disclaimer for which I am trying to work around with my suggestion of using tags and eventtypes:

Important: Data from a renamed source
type will only use the search-time
configuration for the target source
type ("cheese_shop" in this example).
Any field extractions for the original
source type ("whoops" in the example)
will be ignored.

If I understand correctly, renaming the sourcetype will also lose the original sourcetype's search-time field extraction etc...

0 Karma

Communicator

Thank you, Burch and this solution is the one we have decided on with the business partner. We are more confident with using the tag solution. Thanks again.

0 Karma

Esteemed Legend

It is not too big a deal if you use sourcetype renaming. In that case, you can still access the original sourcteype as _sourcetype.

http://docs.splunk.com/Documentation/Splunk/6.4.1/Data/Renamesourcetypes

The main concern is that any apps that you might like to use that exploit Windows events will not work out of the box without you adjusting them to include _sourcetype.

Communicator

Great timing, Mr Woodcock. I was just reading about using the rename stanza. I can appreciate this method more than changing the sourcetype altogether. I appreciate the speedy response as always!

0 Karma