My query is something like this,
index=anything sourcetype=something OWNERGROUP="Helloworld" OR OWNERGROUP="Hellomars" CASETYPE=1|eval Start=(strptime(SUBMITDATE,"%F%T")+3600)|where Start>relativetime(now(),"--7d")|dedup CASEID|eval Priority="P"+tostring(PRIORITY+1)|search STATUS=1 OR STATUS=2 OR STATUS=3|stats count as Total"
In verbose mode am getting 1120 count where as in fast mode am getting 883. In saved dashboard am getting 883 as count.
You are going to need to determine examples of events that are missing, and determine why they are failing in fast mode. Run this each way and output to a csv file, then compare the two csv files, and examine the records that come out under verbose mode but not over fast mode.
index=anything sourcetype=something OWNER_GROUP="Hello_world" OR OWNER_GROUP="Hello_mars" CASE_TYPE=1|eval Start=(strptime(SUBMIT_DATE,"%F%T")+3600)|where Start>relative_time(now(),"--7d") | dedup CASE_ID|eval Priority="P"+tostring(PRIORITY+1)|search STATUS=1 OR STATUS=2 OR STATUS=3 | table _time _raw OWNER_GROUP CASE_TYPE Start CASE_ID Priority PRIORITY STATUS
I suspect that some field is either overrriding START or STATUS, or possibly CASE_ID, and resulting in the loss of records.
This should not be surprising at all. You need to be aware of what
fast mode is; there is no free lunch here. One of the main differences is that auto-kv expansion of KVP-encodings in your events are not done. My suspicion is that some of your events that are not covered by an explicit field extraction still do have things like
... STATUS=1 ... inside the raw text. So if this does not get extracted directly, then in
fast mode, the
STATUS field will not exist, however in
verbose mode (unless this is disallowed with
KV_MODE = none for this sourcetype), the
KV_MODE=auto will happen and create the
STATUS field. There is no mystery here. That is exactly how
fast mode is supposed to work. You have to understand both your data and your field extractions before you can "trust"