Dashboards & Visualizations

How to prevent TimeRangePicker from inheriting timerange from upstream search?

Contributor

I have a couple of searches which feed a pulldown, and a checkboxPulldown.
The problem is that the timerange (only 2 minutes) of the search that feeds the checkboxPulldown is immediately applied to TimeRangePicker after the checkboxPulldown gets its data.
If I use a HiddenSearch, then the timerange does not get assigned to TimeRangePicker. The problem is that I need the Search to not be hidden as it gets $foo$ variables from upstream.
How can I prevent this?

0 Karma
1 Solution

SplunkTrust
SplunkTrust

It feels to me like the purpose of the 2-minute timerange is just to make the Pulldown/CheckboxPulldown modules load faster.

Assuming that's the case, the approach I recommend is that instead of limiting that search by time, limit it with a | head 1000 or | head 10000. This will actually provide a better limit because Splunk will stop getting events off disk extremely quickly even if the data is unusually dense in time.

And as a side effect, since you won't be setting any timerange upstream of your TimeRangePicker, the TimeRangePicker won't have this troublesome behavior.

However.. If that doesn't work for you you can also whack away the timerange args like so:

<module name="Search">
  <param name="earliest"></param>
  <param name="latest"></param> 

Put that downstream from the Search that has the 2minute timerange, but upstream from the TimeRangePicker, and it'll basically shield the TRP from the 2minute timerange.

View solution in original post

SplunkTrust
SplunkTrust

It feels to me like the purpose of the 2-minute timerange is just to make the Pulldown/CheckboxPulldown modules load faster.

Assuming that's the case, the approach I recommend is that instead of limiting that search by time, limit it with a | head 1000 or | head 10000. This will actually provide a better limit because Splunk will stop getting events off disk extremely quickly even if the data is unusually dense in time.

And as a side effect, since you won't be setting any timerange upstream of your TimeRangePicker, the TimeRangePicker won't have this troublesome behavior.

However.. If that doesn't work for you you can also whack away the timerange args like so:

<module name="Search">
  <param name="earliest"></param>
  <param name="latest"></param> 

Put that downstream from the Search that has the 2minute timerange, but upstream from the TimeRangePicker, and it'll basically shield the TRP from the 2minute timerange.

View solution in original post

SplunkTrust
SplunkTrust

Oh that can be an even better way to go. Make sure you read or re-read the "Introduction to postProcess" page in the sideview docs because it saves you headaches from postprocess confusion in the long run. Splunk's postprocess mechanism is great but it has some common pitfalls.

Contributor

Great suggestions which I will keep in mind next time I see this issue.
As I needed this to work right away I searched and found another work around which turned out to be an even better design.
I made the HiddenSearch the base search, and used postProcess in both pulldown and checkboxPulldown to run subsearches so as to set their options. This way I didn't need another search.
Once again thank you so much for your help.