That sounds very much like report acceleration / data model acceleration. Both ways accelerate a search every X minutes and load the most recent minutes on the fly transparently without the user noticing. As for the question itself, sure - just remember to apply whatever reporting happened to the summary search in the last-five-minutes-search as well. ... View more

PostProcess and Scheduled Searches are separate techniques that do quite different things. As such you can't really compare one to the other. Nor are you forced to pick one over the other for that matter - you can use postProcess on scheduled jobs just fine... So let me back up and explain the usefulness of scheduled saved searches versus postprocess. 1) Scheduled Saved Searches You're taking a search or a report and telling splunk to run it on a schedule. When a user then hits a dashboard that references this given search or report, by default that dashboard will then not re-run the search "on demand" - instead the dashboard will grab the most-recently-run results. The most-recently-run results will load almost instantly, whereas if the dashboard ran the search on demand it would take some number of seconds roughly proportional to the number of events Splunk has to get off disk. 2) Postprocess PostProcess is a way to use the Splunk Search API, and by extension it covers a range of modules and techniques that use that API. The basic idea is that given some search result (and it can be a scheduled search result or a result from a search run "on demand"), you can use postprocess to carve up the results in more than one way, such that you can serve more than one panel or more than one "thing" using the same search results. Let's take a simple example and walk through the benefits of both! Let's say you have a very simple dashboard where you want to show the user two things. A) a graph of traffic over time split by the top users (in SPL, lets say * | timechart count by username ) B) A table showing the 10 most active overall users (in SPL, lets say `* | top 10 username" 1) Enter "scheduled saved searches" - You can either let these both be ad-hoc searches, OR you can schedule one or both as separate scheduled saved searches. If you schedule one or both, the panels served by the scheduled results will load almost instantly. Any ad-hoc panel will take a while to populate. 2) OK. Now enter "Postprocess" - This is a very different thing. With postprocess you can actually refactor this picture such that only one search result is needed to give the data to both panels. * | bin _time span=1h | stats count by _time username and that search is carved up by two different postprocess searches -- | timechart sum(count) by username and | stats sum(count) as count by username And that's it. The postprocess machinery has nothing to do with how that search result came into existence -- it might be a scheduled search result, or it might be ad-hoc. ... View more

Presumably you're using a Sideview Checkbox module together with the Sideview AutoRefresh module and using the AutoRefresh module's normal mode of "pushDownstream". In this default mode the AutoRefresh module just initiates a push every N seconds. (and from there it's the framework and the downstream modules that work out whether or not any searches have to be dispatched.) If the second tab contains searches that you don't want autorefreshed, I think the way forward is simpler than trying to uncheck/check the autorefresh checkbox up above (which solution by the way would lead you into some second-order interaction problems). But at a high level it seems that what you want is a state where the checkbox and autorefresh effectively become useless or irrelevant whenever the second tab is open, and relevant when the first tab is open. 1) EASY: move both the Checkbox and the AutoRefresh inside the first tab. You are done. yay. The autorefreshing and the checkbox are only relevant inside the first tab. the user is not confused and you have no extra moving parts to remember later. 2) A BIT WEIRD: If we left the checkbox and the autoRefresh at the top and if we just put a Button module at or near the top of the content inside the second tab, and set both allowAutoSubmit and allowSoftSubmit to False on that Button, then the push from the upstream AutoRefresh will die there. Only the user clicking the second tab's green Button can make the second tab's searches dispatch. Granted, the user might be a little confused, since when the second tab is open the checkbox appears to say autorefresh is on, yet the second tab never autorefreshes... 3) HARDER: do the same as #2 above but also throw a ShowHide module into the content of each Tabs. These ShowHide modules could make the autorefreshing Checkbox control only appear when the first tab is open... ShowHide is a nice and simple invisible module. When a push hits it, it can show zero or more CSS selectors, and optionally hide zero or more other CSS selectors. So in tab 1 you would have: <module name="ShowHide"> <param name="show">.Checkbox</param> </module> and in tab 2 you would have <module name="ShowHide"> <param name="hide">.Checkbox</param> </module> And you might use the cssClass param on the Checkbox to give yourself a more fine grained CSS selector than ".Checkbox". But I suspect the answer is more like #1 - rearranging the page flow and thus the UI to suit your interaction requirements more closely. ... View more

Wouldn't this achieve the desired output without any streamstats shenanigans? ... | timechart limit=12 useother=f span=2m count by URL ... View more