Dashboards & Visualizations

Can TimeRangePicker be on the Top of a HiddenSavedSearch?

Builder

I have a view of a table inside a timerangepicker where i need to call a HiddenSavedSearch.



True
Last 30 days


LOGSUMMARYTABLE
avg_range
Online log errors summary

True


True
False

100

100





The following error is appearing saying Configuration Error: HiddenSavedSearch is being run as a schedule and it's configured to listen to time picker. Schedule result will not be shown

How to remove such error from my dashboard?
alt text

0 Karma
1 Solution

Builder

I have solved the issue partially using Search module from sideview. But i need to know if i can make execution time more fast if i select a big time range.


True
Last 30 days


stashedEarliest
$search.timeRange.earliest$

stashedLatest
$search.timeRange.latest$



My Search Code goes Here
| set union [search sourcetype="log4j" ....


$stashedEarliest$

10

View solution in original post

0 Karma

Builder

I have solved the issue partially using Search module from sideview. But i need to know if i can make execution time more fast if i select a big time range.


True
Last 30 days


stashedEarliest
$search.timeRange.earliest$

stashedLatest
$search.timeRange.latest$



My Search Code goes Here
| set union [search sourcetype="log4j" ....


$stashedEarliest$

10

View solution in original post

0 Karma

SplunkTrust
SplunkTrust

Oh ok. If you need the stashed timerange further down into the page, besides the XML posted here that makes sense. But that particular <param name="earliest">$stashedEarliest$</param> should be deleted cause it's now redundant.

0 Karma

Builder

I need those values to be saved all along my inline drilldowns:)

0 Karma

SplunkTrust
SplunkTrust

What you're doing doesn't make any sense here. If you're using the Search module after all then you don't need any of this $stashedEarliest$ logic. Delete both ValueSetter modules, delete the <param name="earliest">$stashedEarliest$</param> and nothing will change from your current behavior.

As to your performance problem, you can almost certainly get better performance by simply rewriting your search. I think it's likely that we can help you rewrite this search to not use the set command and run the search more efficiently.

Beyond that, summary indexing, report acceleration, etc.

0 Karma

SplunkTrust
SplunkTrust

Well, the error is correct, in that HiddenSavedSearch has a useHistory param, it defaults to auto, and this means that if your savedsearch is scheduled, you've configured the view to use the scheduled job, and thus the timerange of the scheduled job. the fact that you've also configured the view to use the timerange from the TimeRangePicker leads to a contradiction.

Often what people want here is to use the timerange of the scheduled job as the initial search results when the page loads, but then to have the TimeRangePicker available for users to pick a different timerange. Unfortunately neither Splunk's HiddenSavedSearch nor Sideview' SavedSearch module really allow this. HiddenSavedSearch gives you the big red error message, and the SavedSearch module will just ignore the TimeRangePicker and use the timerange from the saved search if one exists...

I've seen people solve this problem by essentially building it both ways and then using Pulldown, Checkbox and/or Tabs modules to make the overall interaction make sense. Let me know more details of what you want the users to be able to do, and I'll try and update my answer.

SplunkTrust
SplunkTrust

You might look into report acceleration. That should allow you to dispatch the search ad-hoc (use SavedSearch and set useHistory to false). The report acceleration should make it run fast.

0 Karma

Builder

I have solved the issue partially using Search module from sideview. But i need to know if i can make execution time more fast if i select a big time range?

0 Karma