Splunk Search
Highlighted

search results

Explorer

Why would these searches return different results? I'm searching over the same time range with both.

index=main sourcetype=ivr host="*apc*" | search start=* end=* ani=* dnis=* | dedup UID

This search returns 1490 events.

index=main sourcetype=ivr host="*apc*" start=* end=* ani=* dnis=* | dedup UID

this search returns 1696 events.

Tags (2)
0 Karma
Highlighted

Re: search results

Contributor

Hi,

well that's strange.. you have to give some value after the Comparator "=". otherwise the search will fail.
open the job inspector ans search for the "normalized_search" and compare them or post it.
In my test both searches have the same normalized search and should return the same amout of events when running over the same time.

Regards,

Andreas

0 Karma
Highlighted

Re: search results

Explorer

Didn't notice the asterisk not showing up...But when I run the search there is an asterisk behind the equal sign.

0 Karma
Highlighted

Re: search results

Explorer

First Search

litsearch index=main sourcetype=ivr ( ( ( sourcetype=summary ) AND ( ( orig_host="*apc*" ) ) ) ) OR ( host="*apc*" ) | 
litsearch index=main sourcetype=ivr host="*apc*" | 
search start=* end=* ani=* dnis=* | 
fields keepcolorder=t "*" "UID" "_bkt" "_cd" "_si" "host" "index" "linecount" "source" "sourcetype" "splunk_server" | 
prededup 1 keepempty=false consecutive=false keepevents=false "UID"

Second Search

litsearch index=main sourcetype=ivr ( ( ( sourcetype=summary ) AND ( ( orig_host="*apc*" ) ) ) ) OR ( host="*apc*" ) 
start=* end=* ( ( ( sourcetype=ivr ) AND ( ( userPhoneNumber="*" ) ) ) ) OR ( ani="*" ) dnis=* | 
litsearch index=main sourcetype=ivr host="*apc*" start=* end=* ani=* dnis=* | 
fields keepcolorder=t "*" "UID" "_bkt" "_cd" "_si" "host" "index" "linecount" "source" "sourcetype" "splunk_server" | 
prededup 1 keepempty=false consecutive=false keepevents=false "UID"
0 Karma
Highlighted

Re: search results

Splunk Employee
Splunk Employee

@jephillips - Just so you know, there is special markup language on this site so certain symbols will transform your post. If you wrap a word in the asterisk symbol * or _, without wrapping it in a code sample, it will italicize the word. If you wish to show the * (i.e. you are displaying sample code), simply click on the Code Sample icon to the right of the Blockquote icon in the formatting toolbar. That is how I was able to edit your post so that the * will display.

0 Karma
Highlighted

Re: search results

SplunkTrust
SplunkTrust

Where did "userPhoneNumber" come from in that second search? That does not look right at all, please check your actual searches again.

0 Karma
Highlighted

Re: search results

Contributor

well normalizedsearch is still the same: for me it is..

litsearch ( index=main sourcetype=ivr ( host=apc OR ( sourcetype=collectd ) ) start="" end="" ani="" dnis="" ) | litsearch ( index=main sourcetype=ivr host="apc" start="" end="" ani="" dnis="" ) | fields keepcolorder=t "*" "UID" "bkt" "cd" "si" "host" "index" "linecount" "source" "sourcetype" "splunkserver" | prededup 1 keepempty=false consecutive=false keepevents=false "UID"

what's your result?

0 Karma
Highlighted

Re: search results

Esteemed Legend

We need to hear from THE MAN on this topic, @landen99. What do you say, Andrew? What is your final word on this issue?

0 Karma
Highlighted

Re: search results

Motivator

(Thank you, Gregg Woodcock, for the vote of confidence.)

It is possible that either you are still getting new events within your time range or that the bundles are out of synch between the search head and the indexers.

On the possibility that the events being indexed between the two searches fall within the time range being searched, the _indextime of the new events may fall outside your window while _time may continue to fall within your time range for awhile. In that case, even the same search will yield different results until the events being indexed stop falling within your time period.

Try the same search until successive attempts yield the same number of events. Then try the two searches without the dedup and compare the number of events. Look for words which assure that a field will be present and search on those instead to improve both accuracy and speed of the search (and to set the real number of events for comparison with the search time extraction performance). It is also worthwhile to verify that the search results are complete and that all indexers are reporting their results fully.

Added: Following DalJeanis' comment in the other answer, the appearance of the field userPhoneNumber in one of the normalized searches shows that a difference in knowledge object bundles yields different results. You may want to check autolookup or alias for that field.

0 Karma