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, |
.*
|
/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 .
|
*
|
The asterisk wildcard matches anything in that specific folder path segment.
Unlike |
[^\\\/]*
|
/foo/*/bar matches the following:
but does not match
A single period ( |
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:
- Begin with
log
. - Contain a single capital letter (from A-Z) or number (from 0-9).
- Contain any other characters.
- 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 defaultWildcards 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 | Include or exclude specific incoming data |
This documentation applies to the following versions of Splunk® Enterprise: 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.9, 7.0.10, 7.0.11, 7.0.13, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.1.9, 7.1.10, 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.1, 8.1.2, 8.1.3, 8.1.4, 8.1.5, 8.1.6, 8.1.7, 8.1.8, 8.1.9, 8.1.13, 8.1.14, 8.2.0, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 8.2.5, 8.2.6, 8.2.7, 8.2.8, 8.2.9, 8.2.10, 8.2.11, 8.2.12, 9.0.0, 9.0.1, 9.0.2, 9.0.3, 9.0.4, 9.0.5, 9.0.6, 9.0.7, 9.0.8, 9.0.9, 9.0.10, 9.1.0, 9.1.1, 9.1.2, 9.1.3, 9.1.4, 9.1.5, 9.1.6, 9.2.0, 9.2.1, 9.2.2, 9.2.3, 9.3.0, 9.3.1, 8.1.0, 8.1.10, 8.1.11, 8.1.12
Feedback submitted, thanks!