toggling between summarized vs. non-summarized dashboards

[Justin_Grant]

Our app leverages summary indexes to get good performance from data-intensive dashboards across millions of events.

But summary indexes are not perfect-- for example, when the app is first installed, dashboards will be blank for a while (lousy out of the box experience), and for really fine-grained reporting (e.g. last 5 minutes) the summary indexes won't be useful.

What is the best practice or pattern for toggling between summarized and non-summarized dashboards?

• Is it best to have two parallel dashboards? And if so, how is this best handled in the app's navigation? Should every navigation node be a 2-item flyont menu, one for summarized vs. non-summarized?
• Or is there some way to toggle a dashboard between a summarized and non-summarized view, without cloning views in the app's navigation menus?
• Or can this seamlessly be integrated with the time picker, so we can use summary indexes for longer-term queries while use regular indexes for short-term queries (e.g. <5 minues)

[gkanapathy]

• I've done this. Just tell users to go to one for short-term reporting, and another for long-term. This doesn't work well if you have more than just (raw, summary), but instead have (raw, hourly summary, daily summary), and even less well if you have "per-minute summary" in there.
• Sure, you can build switchers into the UI using, e.g. the TabSwitcher module. I have not done this, and I am not certain if switcher modules will actually dispatch every search on the page (even the hidden ones), which would put a considerably higher load in the system. From the user point of view, I guess it's slightly easier, but you're still telling them to go to a different place for each granularity. (With the possible added problem of them running, e.g., raw searches in a hidden module while they're looking at daily summaries.)
• No, but perhaps when a future "report acceleration" feature makes it way into the product, where summaries are transparently integrated into the raw index, this won't be needed. This is not going to be available real soon though.

It might be worthwhile request to have a new TimePicker module that allowed one to specify a different searches or search templates or HiddenSearches depending on the size of the range that was selected. That would allow this problem to be solved by the UI/view developer quite cleanly.

---

Oh, one more possibility is to just display the searches from a the summary, and modify the drill-down from the summary charts and tables to go to the raw data. This can be done in the view XML. It obviously only works if you've only got (raw, summary), and doesn't work if you have (raw, per-minute summary, hourly summary, daily summary) data.

[gkanapathy]

Also, added another suggestion above.

[gkanapathy]

Well...I just had two different views in the menus, and you tell the users to pick the one that's appropriate (more detail vs faster). The module, well, in theory you can supply your own, but that type of customization is unsupported in the Splunk product. However, my thought was that this is a common enough problem that it is something Splunk should include in the core product. It doesn't require changes in anything underlying and is probably useful for other things.

[Justin_Grant]

re: "just tell users to go to one..." how do you set up the navigation menus? re: "new TimePicker module", do you mean a module that we can build into an app, or something that Splunk product must include?