Wildcards
When you need to cast a wide net in your searches, you can use wildcards to match characters in string values. The wildcard that you use depends on the command that you are using the wildcard with:
- eval and where commands
- Use the LIKE function with the percent ( % ) symbol as a wildcard for matching multiple characters. Use the underscore ( _ ) character to match a single character. See the like (TEXT, PATTERN) function in the list of Comparison and Conditional eval functions.
- All other commands
- Use the asterisk ( * ) character as a wildcard to match an unlimited number of characters in a string. For example,
"my*"
matchesmyhost1
andmyhost.ny.mydomain.com
.
Be efficient and specific
If you specify an asterisk with no other criteria, you are asking to match everything. Yes, everything. All events are retrieved, up to the maximum limit. A search to match everything is both inefficient and time consuming. You'll use a lot of system resources, which can prevent others from running their searches. Additionally, you might wait a long time for your search results.
To avoid these problems, be as specific as you can in your search criteria.
The more specific your search terms are, the more efficient your search is. Sometimes that means not using a wildcard. Searching for a specific word or phrase is more efficient than a search that uses a wildcard. For example, searching for access denied
is always better than searching for access*
.
Best practices for using wildcards
The best way to use a wildcard is at the end of a term, such as fail*
.
Specify a field-value pair whenever possible to avoid searching the raw
field, which is the entire event. For example: status=fail*
.
When using wildcards in searches, carefully consider whether you're getting the results you expect. For example, the following searches containing wildcards do not return any events, as expected:
NOT *
sourcetype=_json NOT *
sourcetype=* NOT *
The following searches containing wildcards do return events, as expected:
sourcetype=*
index=*
Using wildcards with index= and NOT
If you want the inverse of a wildcard when using index=
and NOT *
, you must use (NOT *)
to produce the most accurate search results. For example, the following searches do not return events, as expected.
index=<index name> (NOT *)
index=* (NOT *)
The following searches incorrectly return events, because NOT *
is not enclosed in parentheses.
index=<index name> NOT *
index=* NOT *
When to avoid wildcard characters
There are several situations in which you should avoid using wildcard characters.
Avoid using wildcards in the middle of a string
Certain searches with wildcard characters in the middle of a word or string might cause inconsistent results. This is especially true if the string contains punctuation, such as an underscore _
or dash -
character.
If your search displays a warning message indicating that a term contains a wildcard with punctuation in the middle of a word or string, rewrite your search. For example, if your search contains the following string:
(host=sh-*splunkcloud* OR host=si-*splunkcloud*)
Modify your search to use the following string instead:
( ( host=sh-* OR host=si-*) host=*.splunkcloud* )
A search that uses a wildcard in the middle of the term returns inconsistent results because of the way in which data that contains punctuation is indexed and searched. For example, suppose you have the following list of product IDs.
DB-SG-G01 DC-SG-G02 MB-AG-G07 MB-AG-T01 SC-MG-G01 SF-BVS-G01 SG-SH-G05 WC-SH-A02 WC-SH-G04
Say you create a search that looks for all of the product IDs that begin with the letter S and end in G01, like this:
productID=S*G01
Your search will fail because of the way that events are indexed. When the events with the product IDs are indexed, the product IDs are broken up into segments. For example, the product ID SC-MG-G01
has these segments: SC
, MG
, G01
. There is no segment that starts with an S and ends with G01, which is what the search productID=S*G01
specifies. Because there are no segments that match your search, no results are found.
The solution to this problem?
- If the number of product IDs is small, specify the exact product IDs in your search rather than using a wildcard. For example:
productID=SC-MG-G01 OR productID=SF-BVS-G01
- If the number of product IDs is large, use a lookup instead of a wildcard.
To learn more about how punctuation can impact using wildcards, see Event segmentation and searching.
Avoid using wildcards to match punctuation
Punctuation are characters that are not numbers or letters. If you want to match part of a string that includes punctuation, specify each string with the punctuation that you are searching for.
For example, you have the following values in the uri_path
field in your events.
/cart.do /cart/error.do /cart/success.do /category.screen /oldlink /product.screen /productscreen.html /show.do /stuff/logo.ico
You want to match every uri_path
that starts with /cart
. The problem is that the paths contain a forward slash ( / ) character and period ( . ) character. Instead of specifying a wildcard character for the punctuation such as /cart*
, specify the punctuation directly in your search criteria. For example,
...uri_path=/cart.do OR uri_path=/cart/error.do OR uri_path=/cart/success.do
Avoid using wildcards as prefixes
When you use a wildcard character at the beginning of a string, the search must look at every string to determine if the end of the string matches what you specify after the asterisk. Using a prefix wildcard is almost like using a wildcard by itself. Prefix wildcards might cause performance issues.
Avoid using wildcards at the beginning of search terms.
Searching for the asterisk character
You can't search for the asterisk ( * ) character directly because the character is reserved as a wildcard.
However, you can search for a term without the asterisk and then use either the where
or regex
command to filter the results.
For example, to search for a term that contains an asterisk such as *78
, use these steps:
- First search for
78
without the asterisk, which returns all events that contain the number. - Follow that with
| regex _raw=\*78
to return only those events that contain*78
.
The backslash ( \ ) is used in the regular expression to not interpret, or escape, the asterisk character. See the regex command.
Other supported wildcards
The LIKE function supports using other wildcards for pattern matching. The percent ( % ) symbol is used as a wildcard for matching multiple characters. The underscore ( _ ) character is used to match a single character.
These wildcards are only applicable to the LIKE function. See like (TEXT, PATTERN) in the list of Comparison and Conditional functions.
You can use the percent ( % ) wildcard anywhere in the PATTERN.
Search command primer | Backslashes |
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!