A search for "ip=100.2.2.2" userid=foobar
(identifying information has been changed) produces 5 results. However, when I remove the quotes and search ip=100.2.2.2 userid=foobar
, there is only 1 result. And NOT ip=100.2.2.2 userid=foobar
returns the remaining 4 results. Why is there a difference in results depending on whether or not there are quotes?
I figured it out. There was a saved entry at Fields >> Field Extractions that was incorrectly extracting the IP for a subset of the events. It was extracting the value as the full string "ip=100.2.2.2" instead of just "100.2.2.2".
I figured it out. There was a saved entry at Fields >> Field Extractions that was incorrectly extracting the IP for a subset of the events. It was extracting the value as the full string "ip=100.2.2.2" instead of just "100.2.2.2".
Good catch. These are tough one to figure out.
Don't format to close the question by clicking on Accept to this answer.
"ip=100.2.2.2" is an exact phrase search and in any search engine the exact phrase search is the most restrictive, so really it's weird that without the quotes you get less results.
Check if there is a difference in the format in which ip=100.2.2.2
appears in all those 5 events. As @ddrillic said, with quotation it does a string based search. Without quotation it expects a field ip
to be present and it's been extracted correctly in only one event, and not in other 4. If possible can you paste the whole raw event, one which is matching and any one which is not matching?
The 4 results that match the NOT ip=100.2.2.2
search look like:
290 <190>1 2017-04-19T09:26:53.529400+00:00 - INFO - REDACTED - Successful authentication. reason=AuthenticateFailed_exception userid=REDACTED ip=REDACTED
This is the one result that matches the ip=100.2.2.2
search
254 <190>1 2017-04-19T09:26:34.042433+00:00 - INFO - REDACTED - attempting to authenticate. userid=REDACTED ip=REDACTED
I've redacted the specific userid and ip for anonymity, but I can confirm the two are identical to each other based on browser search matching for both strings.
It seems like the underscore in the first (failed) query might be a relevant difference?
I figured it out. There was a saved entry at Fields >> Field Extractions that was incorrectly extracting the IP for a subset of the events. It was extracting the value as the full string "ip=100.2.2.2" instead of just "100.2.2.2".
@jjan... Please convert your comment to answers and Accept the same. While searching for fields with minor segmentation like IP address, it is better to use TERM()
function. Refer to documentation: https://docs.splunk.com/Documentation/Splunk/latest/Search/UseCASEandTERMtomatchphrases