I encountered a very weird behaviour. This has now also been reported as bug.
Update: I did manage to create some fake data now and further isolated the issue. I cannot attach the files nor links. So you'd need to create them on your own.
So first run this to create some fake logs:
| makeresults | eval id=1 | eval number= 816341959
| append [|makeresults | eval id=1 | eval number=816295885]
| fields - _time
| outputlookup testlog.csv
And now run this to create a lookup:
| makeresults | eval color="Purple" | eval number=816295885 | fields - _time
| outputlookup testlookup.csv
Now that we got the files, run this:
|inputlookup testlog.csv
| eval number=mvindex(number,0,0)
| lookup testlookup.csv number output color as color1
| eval mydump=number
| eval mydump2=color
| eventstats dc(test.id) as ids by number
| lookup testlookup.csv number output color as color2
| search number=816295885
Result:
color1 is null
color2 is "Purple" as it should be
Things you can play around with:
- Remove the mvindex -> it will populate color1 correctly
- Remove the eventstats -> it will populate color1 correctly (even though there is nothing which affects this field at that point)
- in the testlog.csv switch around the two values -> it will populate color1 correctly
- switch the value which is NOT looked up (816341959) to 100 -> it will populate color1 correctly (from 816295885)
- now switch the value which is NOT looked up to 916341959 -> it will populate color1 correctly (from 816295885)
This basically means that with numbers in this range of ~816295885 splunk becomes unreliable, if it is at a location of a similar lookup, which is extremely bad.
You can even do this:
| makeresults | eval number= 816295885
| append [ makeresults | eval number=816341959]
| table number
| lookup testlookup.csv number output color
Even though only 816295885 is in the lookup, the color will also be found for 816341959, which is even more extremely bad I guess.
Splunk Version 7.2 was used in this case. Don't know if this is version specific.
