This search produced valid data last night. It was saved. Launching the saved search shows valid time series data
index=flowspaces sourcetype="growl_xml" | eval binder=(if((application="Hyperspaces") OR (application="Dock Spaces"),1,0)) | eval unbinder=(if((application="Keyboard Maestro"),1,0)) | transaction binder startswith=(binder=1) endswith=((binder=1) AND (unbinder=0)) maxevents=2 maxpause=15m maxspan=15m keepevicted=true maxopenevents=10 maxopentxn=10 mvlist=true | eval eventcount1=eventcount | eval switchorder=(mvjoin(application,"-")) | where application!="Keyboard Maestro" | timechart limit=6 count(switchorder) by switchorder usenull=F useother=f
Running the same search live produces the same data except with one important difference: a 4 month SPIKE where none of the events are made part of the transaction. Different runs put the spike randomly in different 4-month sections.
So is this a memory issue?
Ok, I had an idea that it might be the maxopenevents and maxopentxn (memory options on transactions) that had something to do with this strangeness.
Experimented first upward and then downward with values for these options.
With only the default values for these memory options the search runs as expected.
I think that the search was run and completed with the default values. Then it is possible that the search was modified in the web ui with the values above, and saved.
The saved data and real search parameters for that data therefore mismatched in the saved search.
Someone else who knows more might confirm or deny this hypothesis with more certainty!
Edit:
Well, it seems like I have a second case. Only this time the live search corrected as per below works fine, but once saved does not correctly group events into transactions for a 2 year period.
Cutting the search string from the bad saved search and pasting into a new search tab to run live, and it works fine.
Its wierd. Maybe saved searches require different memory options than live searches to run correctly?
Ok, I had an idea that it might be the maxopenevents and maxopentxn (memory options on transactions) that had something to do with this strangeness.
Experimented first upward and then downward with values for these options.
With only the default values for these memory options the search runs as expected.
I think that the search was run and completed with the default values. Then it is possible that the search was modified in the web ui with the values above, and saved.
The saved data and real search parameters for that data therefore mismatched in the saved search.
Someone else who knows more might confirm or deny this hypothesis with more certainty!
Edit:
Well, it seems like I have a second case. Only this time the live search corrected as per below works fine, but once saved does not correctly group events into transactions for a 2 year period.
Cutting the search string from the bad saved search and pasting into a new search tab to run live, and it works fine.
Its wierd. Maybe saved searches require different memory options than live searches to run correctly?