Dashboards & Visualizations

How to prevent TimeRangePicker from inheriting timerange from upstream search?

sansay
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

sideview
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

sideview
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.

sideview
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.

sansay
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.

Get Updates on the Splunk Community!

Updated Team Landing Page in Splunk Observability

We’re making some changes to the team landing page in Splunk Observability, based on your feedback. The ...

New! Splunk Observability Search Enhancements for Splunk APM Services/Traces and ...

Regardless of where you are in Splunk Observability, you can search for relevant APM targets including service ...

Webinar Recap | Revolutionizing IT Operations: The Transformative Power of AI and ML ...

The Transformative Power of AI and ML in Enhancing Observability   In the realm of IT operations, the ...