Loading notification on Dashboard

[PaulaCom]

Hi All 

In my current dashboard i have several text input that colleagues can use to find varies information. Sometimes it takes a while for their information to appear. 

Is there a way to add a loading notification / alert to advise colleagues that Splunk is retrieving the information but may take some time? 

The delay unusually is only for their 1st search and thereafter the searches are pretty much instant. 

Many thanks

Paula  

[_JP · Accepted solution]

Are you talking about the various dropdowns/multiselect inputs for a Dashboard, and waiting for that data to populate so they have something to select?  Like this screenshot:

If so, one way to speed this up is run the search behind those dynamic values as a scheduled search, have that query put the results into a lookup.  And then, the search to populate your inputs are just loading that lookup with | inputlookup.

If this is what you're thinking, then I can provide some more resources to get headed in that direction.  Also, are you building dashboards in SimpleXML or Dashboard Studio?

[PaulaCom]

Morning 

Thank you for the response. The Dashboard is a Classic Dashboard, i definitely don't see as many options for inputs as you have above. 

I'll have a look at the lookup option to speed up the search. that's something i never thought of thank you. 

kind regards, 

Paula  

[_JP]

I'll preface this with there are some best practices I'm skipping over for a production dashboard - formally creating a lookup & setting permissions, scheduling a saved search (aka report) to create this lookup, etc.  I'm also assuming you have admin access to your environment since this example uses data you would have in your index=_internal.  The important thing here is the concept of referencing a lookup and not having an in-line search.

I have attached an XML so you can see the SimpleXML dashboard I created for this example.  The left input dropdown does an in-line search to populate the dropdown values (and this could be what you're seeing as slow).  This means it is searching over, and the right input dropdown still runs a search, but all that search does is load a lookup csv file for the data - it's really quick!

The search I run for the left input is the following, and it is configured in the XML to look over the past 120d:

index=_internal | dedup component | table component | sort component

  The search I run for the right input is the following, and the timeframe doesn't matter - all it does is load a csv, but the results in that csv lookup are the same format/data as the search above:

 | inputlookup internal_component_list.csv

Note:  that's not the real search that generates the csv.  It is just loading it.  To generate the csv, I ran the following search.  It's real similar to the one for the left dropdown, but I added the outputlookup command to make that csv:

index=_internal earliest=-120d | dedup component | table component | sort component | outputlookup internal_component_list.csv

You can take this outputlookup search and schedule to run once a week (or however often is appropriate for your data).  The key is this search can be scheduled to run behind the scenes when no one is waiting on the results.

I just scheduled it as a report:

And its search configuration looks like this:

And for this example I decided to schedule it weekly (but notice that the search looks back 120 days with the earliest=-120d in the SPL).  I'm essentially building my dropdown data weekly from the past 120 days of events in _internal: