Getting Data In

Where and how to define TIME_FORMAT in props.conf?

Builder

I have props.conf in 3 different directories as follows:

1) Splunk_Home/etc/apps/learned/local/props.conf

[splunk-config-too_small]
PREFIX_SOURCETYPE = True
SHOULD_LINEMERGE = False
is_valid = True
maxDist = 9999

[first_install-too_small]
PREFIX_SOURCETYPE = True
SHOULD_LINEMERGE = False
is_valid = True
maxDist = 9999

[splunk-config-2]
MAX_TIMESTAMP_LOOKAHEAD = 40
SHOULD_LINEMERGE = False
is_valid = True

2) Splunk_Home/etc/apps/search/local/props.conf

[splunkd]
EXTRACT-fields = (?i)^(?:[^ ]* ){2}(?:[+\-]\d+ )?(?P[^ ]*)\s+(?P[^ ]+) - (?P.+)

[splunk_web_service]
EXTRACT-useragent = userAgent=(?P[^ (]+

3) Splunk_Home/etc/apps/splunkforwarder/local/props.conf

stanza that matches every string, using a priority over 100
enables us to override even literal matches. So here we disable:
(1) header line processing

[(::)?...]
CHECK_FOR_HEADER = false
priority         = 10001

Now if want to add a indexing time_format to which props.conf I need to use, and what is the difference between these 3 props.conf? and which among these is main format?

So if I given a time_format, what is the deployment command to use to get these changes deployed in different OS's?

1 Solution

Influencer

You should put TIME_FORMAT in a props.conf on the Splunk system that is parsing your data usually (there are exceptions) this is not on your Universal Forwarder on every system collecting logs, but rather on your indexers or intermediate heavy forwarders (depending on your architecture).

For a wicked in depth detail outline of where TIME_FORMAT comes into play, check out How Indexing Works on the Splunk Wiki or see one of the recordings of Amrit's .conf presentation on How Splunkd Works. Slides are Here the recording is Here, and other .conf2015 sessions are here.

Now that you've identified the correct Splunk systems to set this attribute on, the question becomes in which props.conf file to place it, or do you make your own somewhere else. Well... what happens is all of the props.conf files come together to make an effective props.conf. So it doesn't matter where (to a degree, you should avoid /default/ unless you're creating your own app... prefer /local/ for your changes), so long as you don't have a conflict in a file with a higher precedence (or a stanza type with a higher precedence within the file itself). Regarding in precedence between different props stanzas the spec file describes this at length including the impact that setting priority has. You can find out about configuration files in general in the docs including about the precedence of files in different locations at different contexts, as well as how to debug precedence issues with btool. Hint on determining precedence between files: TIME_FORMAT is something that's applied in the global context.

Finally, deploying such changes depends heavily on your architecture and how you're managing changes. With standalone indexers or heavy forwarders, you could be using a Deployment Server. With an indexer cluster, you would want to rely on using the Cluster Master to push such configurations out. But you could also be using a tool such as Chef, Puppet, Ansible, Salt, Fabric, SCCM, or many others to manage configuration for your deployment and you would want to fit into that system if applicable for your organization

Hope this helps... and one more thing, don't offer "high points for suggestions or ideas" in the future. If your question is clear enough, and someone with knowledge and time to answer sees it, they will. If you find the content particularly valuable you'll vote up the post. This is expected behavior, no need to resort to such bribes in this community of volunteers.

View solution in original post

Influencer

You should put TIME_FORMAT in a props.conf on the Splunk system that is parsing your data usually (there are exceptions) this is not on your Universal Forwarder on every system collecting logs, but rather on your indexers or intermediate heavy forwarders (depending on your architecture).

For a wicked in depth detail outline of where TIME_FORMAT comes into play, check out How Indexing Works on the Splunk Wiki or see one of the recordings of Amrit's .conf presentation on How Splunkd Works. Slides are Here the recording is Here, and other .conf2015 sessions are here.

Now that you've identified the correct Splunk systems to set this attribute on, the question becomes in which props.conf file to place it, or do you make your own somewhere else. Well... what happens is all of the props.conf files come together to make an effective props.conf. So it doesn't matter where (to a degree, you should avoid /default/ unless you're creating your own app... prefer /local/ for your changes), so long as you don't have a conflict in a file with a higher precedence (or a stanza type with a higher precedence within the file itself). Regarding in precedence between different props stanzas the spec file describes this at length including the impact that setting priority has. You can find out about configuration files in general in the docs including about the precedence of files in different locations at different contexts, as well as how to debug precedence issues with btool. Hint on determining precedence between files: TIME_FORMAT is something that's applied in the global context.

Finally, deploying such changes depends heavily on your architecture and how you're managing changes. With standalone indexers or heavy forwarders, you could be using a Deployment Server. With an indexer cluster, you would want to rely on using the Cluster Master to push such configurations out. But you could also be using a tool such as Chef, Puppet, Ansible, Salt, Fabric, SCCM, or many others to manage configuration for your deployment and you would want to fit into that system if applicable for your organization

Hope this helps... and one more thing, don't offer "high points for suggestions or ideas" in the future. If your question is clear enough, and someone with knowledge and time to answer sees it, they will. If you find the content particularly valuable you'll vote up the post. This is expected behavior, no need to resort to such bribes in this community of volunteers.

View solution in original post

Builder

I really appreciate your time and valuable information you had provided. Since I've been new to Splunk these slides and documents will be definately helpful.

0 Karma

Builder

high points will be awarded for any suggestions or ideas....

0 Karma