Specify input paths with wildcards

You can configure inputs manually by editing the inputs.conf configuration file. In Splunk Cloud Platform, you can edit this file on a forwarder that collects the data. In Splunk Enterprise, you can edit this file on your Splunk Enterprise instance.

Input path specifications in the inputs.conf file do not use regular expressions (regexes) but rather wildcards that are specific to the Splunk platform. To specify wildcards, you must specify file and directory monitor inputs in the inputs.conf file.

When you configure an input path that has a wildcard, the Splunk platform instance must have at least read access to the entire path to the file you want to monitor with the wildcard. For example, if you want to monitor a file with the path /var/log/server_a/tree_b/directory_c/file.log, the instance must have read permission in the following directories:

• var
• log
• server_a
• tree_b
• directory_c

If it does not have read access to all of the directories in the path, it cannot read the file, even if it has read access to the file directly.

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. See the following table for a description of the wildcards you can use and examples:

Wildcard	Description	Regex equivalent	Examples
...	The ellipsis wildcard searches recursively 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 /foo/1/bar.log, /foo/2/bar.log, /foo/1/2/bar.log, and so on. It does not match /foo/bar.log or /foo/3/notbar.log. Because a single ellipse searches recursively through all folders and subfolders, /foo/.../bar.log matches /foo/.../.../bar.log.
*	The asterisk wildcard matches anything in that specific folder path segment. Unlike ..., * does not recurse through subfolders.	[^\\\/]*	/foo/*/bar matches the following: /foo/1/bar /foo/2/bar but does not match /foo/bar /foo/1/2/bar /foo/m*r/bar matches /foo/mr/bar, /foo/mir/bar, /foo/moor/bar, and so on. /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, the Splunk platform splits elements of a monitoring stanza into segments. Segments are blocks of text between directory separator characters (/ or \) in the stanza definition. If you configure 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 want to monitor files or directories with those characters in the file or directory names. The following example monitors the /var/log/log(a|b).log file:

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

The (a|b) is not treated as a regular expression because no wildcards are present.

The following example monitors all files in the /var/log()/ directory that begin with log and have the .log extension:

[monitor:///var/log()/log*.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, treats the metacharacters as a regular expression and matches files to monitor accordingly. Consider the following example:

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

This example 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 *.

The following example monitors all files in any subdirectory of the /var/ directory named loga.log or logb.log:

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

treats (a|b) as a regular expression because of the wildcard ... in the previous stanza segment.

Consider the following example:

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

This example monitors all files in any subdirectory of the /var/ directory that meet the following conditions:

1. Begin with log.
2. Contain a single capital letter (from A-Z) or number (from 0-9).
3. Contain any other characters.
4. End in .log.

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

Here are sets of functional and not functional examples:

Functional examples

[monitor:///var/splunk/logA.log] (functional)
[monitor:///var/home/splunk/log0934213.log] (functional)
[monitor:///var/home/log0934213.log] (functional)
[monitor:///var/splunk/log1.log] (functional)
[monitor:///var/splunk/logA_3254.log] (functional)

Not functional examples

[monitor:///var/log093413.log] (not functional)
[monitor:///var/wer235.log] (not functional)
[monitor:///var/splunk/logA.log1] (not functional)
[monitor:///var/splunk/Alog342.log] (not functional)

Input examples

To monitor /apache/foo/logs, /apache/bar/logs, and /apache/bar/1/logs, create the following stanza:

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

To monitor /apache/foo/logs, /apache/bar/logs, but not /apache/bar/1/logs or /apache/bar/2/logs, create the following stanza:

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

To monitor any file directly under /apache/ that ends in .log, create the following stanza:

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

To monitor all log files recursively in D:\Program Files\Splunk\etc\apps, create the following stanza:

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

To monitor any file under /apache/ under any level of subdirectory that ends in .log, create the following stanza:

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

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

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

The tailing logic becomes ^\/var\/log/.*/[^/]*\.log$

Therefore, /var/log/subfolder/test.log matches, but /var/log/test.log does not match and will be excluded. To monitor all files in all folders, make the following changes:

[monitor:///var/log/]

whitelist=\.log$

recursive=true

#true by default

Wildcards and allow lists

Splunk Enterprise defines allow lists and deny lists with standard Perl Compatible Regular Expression (PCRE) syntax. Splunk Cloud Platform doesn't define allow lists and deny lists natively in this way.

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

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

For example, in *nix, if you specify the [monitor:///foo/bar*.log] stanza in the inputs.conf configuration file, Splunk Enterprise translates the path into this:

[monitor:///foo/]
whitelist = bar[^/]*\.log$

On Windows, if you specify the [monitor://C:\Windows\foo\bar*.log] stanza in the inputs.conf file, Splunk Enterprise translates the path into this:

[monitor://C:\Windows\foo\]
whitelist = bar[^\\]*\.log$

In Windows, allow list and deny list rules don't support regular expressions that include backslashes. Use two backslashes (\\) to escape wildcards.