Hello,
A while ago, we updated from 6.5.2 to 7.3.4, and only now I noticed a very bizarre bug and different behaviour than from the old version.
We use summary indexes a lot. You often have daily or hourly summaries, and the summary data should have the timestamp of that range, right?
Let's say daily, search is setup to collect from -1d@d to @d, and is scheduled to run at 2:32am on July 8.
simple meaningless example search:
index=_internal source=splunkd (host=hostnameA OR host=hostnameB) | stats count
When this runs on July 8, 2:32am it will generate a summary entry with a count and a timestamp of July 7 midnight.
Now, when you use inputlookup as a filter method, the time when the search ran is used instead.
Simple lookup table and search:
test.csv:
host
hostnameA
hostnameB
index=_internal source=splunkd [| inputlookup test.csv | fields host] | stats count
Now this will generate a summary entry with a count and timestamp of July 8, 2:32am!
While this is as bad as it is, one thing is even worse: This makes it impossible to backfill summaries in a meaningful way. The time used when inputlookup comes into play, it's not the scheduled time, but the time the search was executed. Therefor, when you backfill for 20 days, all data for those 20 days will have almost the same timestamp, from when you started to execute the backfill.
I tried
index=_internal source=splunkd | search [| inputlookup test.csv | fields host] | stats count
as well,. but it is broken in the same way.
Does anybody know if that is fixed in a later version? This must be a very bizarre bug, right?
