Splunk Cloud

Getting Data In

Specify input paths with wildcards

You can configure inputs manually by editing the inputs.conf file. Input path specifications in inputs.conf do not use regular expressions (regexes) but rather Splunk-defined wildcards. This topic discusses how to specify these wildcards in a path in inputs.conf. To specify wildcards, you must use inputs.conf to specify file and directory monitor inputs.

Wildcard overview

A wildcard is a character that you can substitute for one or more unspecified characters when searching text or selecting multiple files or directories. You can use wildcards to specify the input path for a file or directory monitor input.

Wildcard Description Reg. Exp. equivalent Example(s)
... The ellipsis wildcard recurses through directories and any number of levels of subdirectories to find matches.

If you specify a folder separator (for example, //var/log/.../file), it does not match the first folder level, only subfolders.

.* /foo/.../bar.log matches the files /foo/1/bar.log, /foo/2/bar.log, /foo/1/2/bar.log, etc., but does not match /foo/bar.log, or /foo/3/notbar.log

Because a single ellipse recurses through all folders and subfolders, /foo/.../bar.log matches the same as /foo/.../.../bar.log.

* The asterisk wildcard matches anything in that specific folder path segment.

Unlike "...", "*" does not recurse through subfolders.

[^/]* /foo/*/bar matches the files /foo/1/bar, /foo/2/bar, etc., but does not match /foo/bar or /foo/1/2/bar.

/foo/m*r/bar matches /foo/mr/bar, /foo/mir/bar, /foo/moor/bar, etc.

/foo/*.log matches all files with the .log extension, such as /foo/bar.log. It does not match /foo/bar.txt or /foo/bar/test.log.

A single period (.) is not a wildcard, and is the regular expression equivalent of \..

For more specific matches, combine the ... and * wildcards. For example, /foo/.../bar/* matches any file in the /bar directory within the specified path.

Wildcards and regular expression metacharacters

When determining the set of files or directories to monitor, Splunk Cloud splits elements of a monitoring stanza into segments. Segments are blocks of text between directory separator characters ("/" or "\") in the stanza definition. If you specify a monitor stanza that contains segments with both wildcards and regular expression metacharacters (such as (, ), [, ], and |), those characters behave differently depending on where the wildcard is in the stanza.

If a monitoring stanza contains a segment with regular expression metacharacters before a segment with wildcards, the metacharacters are treated literally, as if you wanted to monitor files or directories with those characters in the file or directory names. For example:

[monitor:///var/log/log(a|b).log]


monitors the /var/log/log(a|b).log file. The (a|b) is not treated as a regular expression because no wildcards are present.

[monitor:///var/log()/log*.log]


monitors all files in the /var/log()/ directory that begin with log and have the extension .log. The () is not treated as a regular expression because it is in the segment before the wildcard.

If the regular expression metacharacters occur within or after a segment that contains a wildcard, Splunk Cloud treats the metacharacters as a regular expression and matches files to monitor accordingly. For example:

[monitor:///var/log()/log(a|b)*.log]


monitors all files in the /var/log()/ directory that begin with either loga or logb and have the extension .log. The first set of () is not treated as a regular expression because the wildcard is in the following segment. The second set of () does get treated as a regular expression because it is in the same segment as the wildcard '*'.

[monitor:///var/.../log(a|b).log]


monitors all files in any subdirectory of the /var/ directory named loga.log or logb.log. Splunk Cloud treats (a|b) as a regular expression because of the wildcard '...' in the previous stanza segment.

[monitor:///var/.../log[A-Z0-9]*.log]


monitors all files in any subdirectory of the /var/ directory that:

• begin with log, then
• contain a single capital letter (from A-Z) or number (from 0-9), then
• contain any other characters, then
• end in .log.

The expression [A-Z0-9]* is treated as a regex because of the wildcard '...' in the previous stanza segment.

Input examples

To monitor /apache/foo/logs, /apache/bar/logs, /apache/bar/1/logs:

[monitor:///apache/.../logs/*]


To monitor /apache/foo/logs, /apache/bar/logs, but not /apache/bar/1/logs or /apache/bar/2/logs:

[monitor:///apache/*/logs]


To monitor any file directly under /apache/ that ends in .log:

[monitor:///apache/*.log]


To monitor all log files recursively in D:\Program Files\Splunk\etc\apps:

[monitor://D:\Program Files\Splunk\etc\apps\*\...\*.log]


To monitor any file under /apache/ under any level of subdirectory that ends in .log:

[monitor:///apache/.../*.log]


The "..." followed by a folder separator will imply that the wildcard level folder will be excluded.

[monitor:///var/log/.../*.log]

the tailing logic will become  '^\/var\/log/.*/[^/]*\.log$'  Therefore, /var/log/subfolder/test.log  will match, but /var/log/test.log  will not match and be excluded. To monitor all files in all folders use: [monitor:///var/log/] whitelist=\.log$ recursive=true #true by default

Wildcards and allow lists

Splunk Cloud defines allow lists and deny lists with standard Perl-compatible Regular Expression (PCRE) syntax.

When you specify wildcards in a file input path, Splunk Cloud creates an implicit whitelist for that stanza. The longest wildcard-free path becomes the monitor stanza, and Splunk Cloud translates the wildcards into regular expressions.

Splunk Cloud anchors the converted expression to the right end of the file path, so that the entire path must be matched.

For example, if you specify

[monitor:///foo/bar*.log]


Splunk Cloud translates this into

[monitor:///foo/]
whitelist = bar[^/]*\.log$ On Windows, if you specify [monitor://C:\Windows\foo\bar*.log]  Splunk Cloud translates it into [monitor://C:\Windows\foo\] whitelist = bar[^/]*\.log$


Note: In Windows, whitelist and blacklist rules do not support regular expressions that include backslashes. Use two backslashes (\\) to escape wildcards.