Splunk Search

Does wildcard sourcetypes in props.conf still work for version 7.0.1?

Builder

Hi,

I know it should be possible to use wildcard sourcetypes in props.conf using a some regex magic, as explained here:

https://www.splunk.com/blog/2014/07/31/quick-tip-wildcard-sourcetypes-in-props-conf.html

The stanza should look something like this:

[(?::){0}acme:*]

However, at the customer where I'm currently at, I don't get it to work. I've tried changing the sourcetype [stanza] to one of the specific sourcetypes I wanted to hit with the wildcard stanza, and then it worked, so I know the problem isn't due to permissions or anything. Can anyone confirm if the wildcard regex magic is still supported in 7.0.1, and if not, if there are any workarounds? If it is supported, does anyone have an idea of what might be the problem?

0 Karma
1 Solution

Builder

I found the answer to my own question. My sourcetypes had slashes in them. As stated in props.conf.

*   matches anything but the path separator 0 or more times.
    The path separator is '/' on unix, or '\' on windows.
    Intended to match a partial or complete directory or filename.

Splunk though that the slashes in my sourcetypes was path separators, and thus the asterisk wildcard "stopped" whenever it hit a slash in the sourcetype name, and didn't match the whole name. The solution was to use an ellipsis (...) instead, which allows for "recursive" matching beyond slashes. The final stanza I ended up with looked like the following.

[(?::){0}acme:...]

View solution in original post

0 Karma

Builder

I found the answer to my own question. My sourcetypes had slashes in them. As stated in props.conf.

*   matches anything but the path separator 0 or more times.
    The path separator is '/' on unix, or '\' on windows.
    Intended to match a partial or complete directory or filename.

Splunk though that the slashes in my sourcetypes was path separators, and thus the asterisk wildcard "stopped" whenever it hit a slash in the sourcetype name, and didn't match the whole name. The solution was to use an ellipsis (...) instead, which allows for "recursive" matching beyond slashes. The final stanza I ended up with looked like the following.

[(?::){0}acme:...]

View solution in original post

0 Karma

Champion

I don't know if wildcard sourcetypes work, but I've had success with using the [default] stanza in props.conf.

[default]
LOOKUP-src_user = user_ips src AS ip
0 Karma

Path Finder

While this works, it doesn't address the need of the OP. If you used a [default] stanza in an app that is shared globally, the LOOKUP would be applied to every single index & sourcetype -- which is no bueno.