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:
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.
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:
||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,
||The asterisk wildcard matches anything in that specific folder path segment.
but does not match
A single period (
For more specific matches, combine the
* 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 (
\) 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
(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:
() 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:
This example monitors all files in the
/var/log()/ directory that begin with either
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
(a|b) as a regular expression because of the wildcard
... in the previous stanza segment.
Consider the following example:
This example monitors all files in any subdirectory of the
/var/ directory that meet the following conditions:
- Begin with
- Contain a single capital letter (from A-Z) or number (from 0-9).
- Contain any other characters.
- End in
[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:
[monitor:///var/splunk/logA.log] (functional) [monitor:///var/home/splunk/log0934213.log] (functional) [monitor:///var/home/log0934213.log] (functional) [monitor:///var/home/Alog0934213.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)
/apache/bar/1/logs, create the following stanza:
/apache/bar/logs, but not
/apache/bar/2/logs, create the following stanza:
To monitor any file directly under
/apache/ that ends in
.log, create the following stanza:
To monitor all log files recursively in
D:\Program Files\Splunk\etc\apps, create the following stanza:
To monitor any file under
/apache/ under any level of subdirectory that ends in
.log, create the following stanza:
... followed by a folder separator implies that the wildcard level folder will be excluded.
The tailing logic becomes
/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:
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.
Monitor files and directories with inputs.conf
Whitelist or blacklist specific incoming data
This documentation applies to the following versions of Splunk® Enterprise: 6.3.0, 6.3.1, 6.3.2, 6.3.3, 6.3.4, 6.3.5, 6.3.6, 6.3.7, 6.3.8, 6.3.9, 6.3.10, 6.3.11, 6.3.12, 6.3.13, 6.3.14, 6.4.0, 6.4.1, 6.4.2, 6.4.3, 6.4.4, 6.4.5, 6.4.6, 6.4.7, 6.4.8, 6.4.9, 6.4.10, 6.4.11, 6.5.0, 6.5.1, 6.5.2, 6.5.3, 6.5.4, 6.5.5, 6.5.6, 6.5.7, 6.5.8, 6.5.9, 6.5.10, 6.6.0, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 6.6.7, 6.6.8, 6.6.9, 6.6.10, 6.6.11, 6.6.12, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.10, 7.0.11, 7.0.13, 7.1.0, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.1.9, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.2.9, 7.2.10, 7.3.0, 7.3.1, 7.3.2, 7.3.3, 7.3.4, 7.3.5, 7.3.6, 7.3.7, 7.3.8, 7.3.9, 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.0.4, 8.0.5, 8.0.6, 8.0.7, 8.0.8, 8.0.9, 8.0.10, 8.1.0, 8.1.1, 8.1.2, 8.1.3, 8.1.4, 8.1.5, 8.1.6, 8.1.7, 8.1.8, 8.2.0, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 7.0.9, 7.1.1, 7.1.10, 7.1.2