when I set 2 conditions for the same field to
where stanza - I get 0 results.
| tstats summariesonly=t count from datamodel="Web.Web" where NOT (Web.url="unknown" OR Web.url="/display*") by Web.src Web.user
Only if I leave 1 condition or remove
summariesonly=t from the search it will return results.
When I remove one of conditions I get 4K+ results, when I just remove
summariesonly=t I get only 1K
Is there any explanation?
The summariesonly takes events only the summary(datamodel acceleration store) and doesnot take into events which are not in the accelerated datamodel (DMA). Hence you would see diff in events with and without summariesonly. In general, based on your search window and if you need to take events into account [ which are not in DMA, do not use summariesonly].
Your search should work. However, how about changing to
| tstats count from datamodel="Web.Web" where (Web.url!="unknown" AND Web.url!="/display*") by Web.src, Web.user
assuming you don't want unknown and urls startings with /display.
I believe Splunk should review this. This is definitely a bug (or just a new approach of how things should work here) - I've discovered another search is not working, because there's a macro with list of exceptions divided by
OR). It works in version 7.2.5 (ES 5.2.2), but not in version 7.3.0 (ES 5.3.0).
As workaround I can follow your
!= approach (thanks for advise) , but this is not a single case where we use
where NOT (...OR ... OR ...) conditions
p.s. And removing the
summariesonly=t lets use
where NOT (...OR ... OR ...), but the scope of results is less than expected. Strange...
we discovered the same bug after the update from 7.2.x to 7.3.2 in our environement today.
... NOT (host=bla AND source=fasel)
doesn't work anymore.
Also this doesn't work:
... (NOT host=bla OR NOT source=fasel)
The workaround with
... (host!=bla OR source!=fasel)
seems to work fine.
Has someone already filed a bug with splunk?
In 8.0 there is the following fix:
2019-07-08 SPL-171713, SPL-171850, SPL-172838, SPL-174080 Search Parser does not fail on tstats w/ complex where clause
Is that it?
There will always be a tiny sliver of new events which are not yet accelerated which will be missed when using
summariesonly=t which is why most content which uses that, has
latest=-5m. In your case, though, it is probably the other (back) end. You are probably only accelerating 7 days of data so that is all that is available REGARDLESS of how wide you make the
timepicker. But without
summariesonly=t, because the matching events still exist in the raw/unaccelerated set the full
timepicker width is searched and the events are found. Your datamodel acceleration details control how far back the acceleration goes in time and you may need to extend this setting.