Splunk Search

The asterisk character is not matching all characters when doing a search, is this a bug?

rsimmons
Splunk Employee
Splunk Employee

The asterisk character is not matching all characters.

A search for :

rectype="bl*query"

returns 0 matching events

BUT

rectype="bl_*_query"

matches 700 as it should

However a search for:

rec=d*s

matches as many results as

rec=dns

Update from user stephenclough:

As the originator of this question, I want specify a little further what the search was intended to do.

the "rectype" field in this data sample has potential values of "bl_left_query", "bl_right_query", "bl_down_query" among others.

I add the context to 1)make more sense of the query that works (rectype="bl_*_query") and 2) show that I'm intending the * wildcard to match more than just a single character as might be suggested by the "rec=dns" search I mentioned.

-THanks for any answers!

1 Solution

Stephen_Sorkin
Splunk Employee
Splunk Employee

The issue here isn't that `*` doesn't match more than one character, it does. The issue is that `*` doesn't match across what we call `breaking` characters, or the characters that break the raw string into segments (typically non-alphanumeric characters).

For efficiency, a search for `rectype="bl*query"` is going to ask the index for individual terms that start with `bl` and end with `query`, but `bl_12:3_query` looks like `bl`, `12`, `3` and `query` in the index.

Depending on your needs, we can change index time segmentation, but this is rarely a good idea. If you know where the breaking characters are in your string, we can change your search. Alternately, to get the behavior you're looking for you can search for `rectype="bl*" AND rectype="*query"`, since both `bl*` and `*query` are satisfied by the index.

We can also consider an enhancement request to support cross-breaker wildcards, but that comes at the detriment of performance.

View solution in original post

Stephen_Sorkin
Splunk Employee
Splunk Employee

The issue here isn't that `*` doesn't match more than one character, it does. The issue is that `*` doesn't match across what we call `breaking` characters, or the characters that break the raw string into segments (typically non-alphanumeric characters).

For efficiency, a search for `rectype="bl*query"` is going to ask the index for individual terms that start with `bl` and end with `query`, but `bl_12:3_query` looks like `bl`, `12`, `3` and `query` in the index.

Depending on your needs, we can change index time segmentation, but this is rarely a good idea. If you know where the breaking characters are in your string, we can change your search. Alternately, to get the behavior you're looking for you can search for `rectype="bl*" AND rectype="*query"`, since both `bl*` and `*query` are satisfied by the index.

We can also consider an enhancement request to support cross-breaker wildcards, but that comes at the detriment of performance.

View solution in original post

blurblebot
Communicator

UPDATE: It's a bug still in 4.1

I opened the case yesterday and received this answer last night:

..."However I did find out that this is a known documented bug that development is currently aware of. It has currently been escalated and we should have have a fix in a near release"

The version is 4.1, and the raw event did not contain an asterisk.

Cheers

steveyz
Splunk Employee
Splunk Employee

what version is this? There was a bug with asterisk searches that was fixed in 4.1, although that particular bug should only have affected cases where the raw event text also contained asterisks.

gkanapathy
Splunk Employee
Splunk Employee

that is, I see the same behavior as the original poster, without any asterisks in my raw text.

0 Karma

gkanapathy
Splunk Employee
Splunk Employee

I don't know what version the original poster is using, but I see the same behavior on 4.0.9.

0 Karma