Surprisingly something like this really works:
index=_internal (earliest=-2d@d latest=@d sourcetype=scheduler) OR (earliest=-1d@d sourcetype=splunkd) | timechart count by sourcetype
see the picture for the result:
This does work, but not the way you think. The earliest and latest work, but the Time Picker is still utilized for the date range. What this means is if you leave the Time Picker as "All Time", that it will have to search through all time and it is extremely slow, especially compared to if you run the search(es) independently.
Your best option to avoid the "searching over a long date range" is to use the
multisearch search command:
| multisearch [ search index=_internal earliest=-2d@d latest=@d sourcetype=scheduler ] [ search sourcetype=splunkd earliest=-1d@d ]
gkanapathy, I would agree with your response, but it would not work in my circumstance (at least with my current knowledge). below is the query that I was trying to do as a Subsearch but was unable to get it to work properly because of what myself and MuS explained above and below.
sourcetype=checks checknumber=XXX | eval earliest=strftime(time-2, "%m/%d/%Y:%H:%M:%S") | eval latest=strftime(_time+2, "%m/%d/%Y:%H:%M:%S") | fields + earliest, latest, sourcetype | format "" "(" "" ")" "OR" ""
A Point to add here:
Searching each time range separately has the earliest and latest times set correctly, but searching them with an OR in between made it so that it windowed the search by the range of the time picker in the search bar. So if that were set to, say, "All Time," it would search over the entire contents of your sourcetypes just to pull out data between those two date ranges. By the same token, if it were set to "Today", it would cut off entries outside of today and give you an incomplete answer. (And if it were set to something that didn't overlap with either of the date ranges in the search, it would give you an error.)