Getting Data In

Override source key in inputs.conf

mixolydian
Path Finder

Hello,

We are helping our indexers get through a bout of too-many-sources. We've applied the short-term solution (a script to trim the number of sources), and are looking at the long-term fix to employ props/transforms changes to normalize the source names through regex. It would seem (to this relative novice) that setting the source in inputs.conf would be an easy way to limit the numbers of sources, but the inputs.conf documentation indicates that this is a Bad Idea:

NOTE: Overriding the source key is generally not recommended.  Typically, the input layer will provide a more accurate string to aid in problem analysis and investigation, accurately recording the file from which the data was retreived.  Please consider use of source types, tagging, and search wildcards before overriding this value.

Apologies if I'm being dim here, but could someone please explain what the pitfalls are here? If our apps are not using the source key specifically, is overriding it a viable option? I appreciate any insight you might have. Thanks.

1 Solution

gekoner
Communicator

mixolydian,

I'm not sure what the pitfalls would be other than what is mentioned in the NOTE. I can tell you I have used Splunk extensively for 3+ years and I always edited the Source of inputs that do not meet my needs.
You have already stated a strong case for editing your Sources values, which having too many is a great reason to edit this.
I have never seen any fallout from doing this. I think the caution comes as a reminder to what you will be doing and the what the ramifications might be.

View solution in original post

gekoner
Communicator

mixolydian,

I'm not sure what the pitfalls would be other than what is mentioned in the NOTE. I can tell you I have used Splunk extensively for 3+ years and I always edited the Source of inputs that do not meet my needs.
You have already stated a strong case for editing your Sources values, which having too many is a great reason to edit this.
I have never seen any fallout from doing this. I think the caution comes as a reminder to what you will be doing and the what the ramifications might be.

mixolydian
Path Finder

Appreciate the concern, gekoner. We released a new version of the app with the source set implicitly and the indexers are much happier now, with no bad side-effects for the app. Thanks for your help!

gekoner
Communicator

mixolydian, I'm curious if everything worked out?

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!

Persistent Queue at TcpOut — One of Splunk's Most Practical Features

Splunk introduced persistent queueing at the tcpout layer as one of the most practical resilience features in ...

Skip the Awkward Silence: Have a .conf-ersation at .conf26

Picture this. You arrive at .conf26 already having your socializing and networking plans mapped out. No ...

Rethinking Zero Trust: From Product Purchases to Logical Control Evidence

Implementing Zero Trust (ZT) across complex environments often falters at the very beginning due to a ...