This is mostly just a curiosity, motivated by this post on how to compare a particular time interval across multiple larger time periods. Effectively the solution seems to be to generate a list of time intervals and run map subsearches on each entry. When I have multiple time periods that I'd like to run stats on, I typically use a multisearch command followed by a chart, as follows: | multisearch [ index=potato et=<et1> lt=<lt2> | eval series=1 ]
[ index=potato et=<et2> lt=<lt2> |eval series=2 ]
.
.
.
[ index=potato et=<etn> lt=<ltn> | eval series=n ]
| timechart count by series I suppose you could make it work by substituting the et's and lt's via subsearch, but it won't work if the number of time intervals, n, is also dynamically generated by some prior search. I know you can use a number of different techniques, but they all have different drawbacks. You could use map, which offers pretty much all the flexibility/dynamic-ness you need (I've abused it plenty of times doing things like map search=`searchstring($searchstring$)` ), but there are performance issues with this as subsearches can time out as it doesn't offer the same optimization as multisearch does when you just need to string multiple streams together. You can just search the entire timerange and use some eval logic to filter out the time intervals you need, but isn't this suboptimal since you're searching more events than you need? Multisearch seems to be great at streaming multiple different time intervals together and I'd love to have that optimization without At this point, would you just have to resort to REST to schedule searches? How would we tie the data together? I'm not very familiar with what is possible with REST as all of my experience is with just plain SPL. In a word, how do we stream events across multiple, dynamically generated time intervals without running into subsearch limitations?
... View more