I'm running 6.1.4
I want to use saved searches in my dashboards for certain types of searches, mostly based on perfmon.
As the searches are tuned / modified all dashboards referencing that saved search will get the updated content.
In order to accomplish this I need to be able to pass parameters to the saved search such as host name, time range, span etc
action.email.reportServerEnabled = 0
alert.track = 0
dispatch.earliest_time = -4h@m
dispatch.latest_time = now
display.general.type = statistics
display.statistics.drilldown = row
display.statistics.overlay = highlow
search = host=$host$ | dedup host | table host
zSavedSearch Proto Eric 1
<input type="text" token="host" searchWhenChanged="true"> <label>Host Filter</label> <default>*DATCDS*</default> </input> <panel> <table> <searchName>Perfmon_Processor_ProcessorTime_Total</searchName> </table> </panel>
How do I pass in $host$ from the input to the saved search?
In case of time range you can pass time as token to your saved search:
<form> <label>Title...</label> <fieldset submitButton="true"> <input type="time" token="time_token" searchWhenChanged="false"> <label>Select Time Range</label> <default> <earliest>0</earliest> <latest></latest> </default> </input> </fieldset> <row> <panel> <chart> <title>Title...</title> <search ref="saved_search"> <earliest>$time_token.earliest$</earliest> <latest>$time_token.latest$</latest> </search> ...
You can pass parameters into saved searches from a dashboard... just not directly.
searchString using this:
| savedsearch Perfmon_Processor_ProcessorTime_Total host=$host$
Remember, this is now an inline search. It'll be called from the user context running the dashboard and cannot make use of any scheduling. Depending on where you insert the host parameter you're not going to match existing report accelerations either. If you need these features, consider moving your knowledge into a data model.
For re-using existing panels, take a look at the Splunk 6.2 feature that lets you create panels and share them with other developers for use in their dashboards. That's not exactly this use case, but still may be useful for your environment.
This works for me:
<form> <fieldset submitButton="false"> <input type="text" token="field1"></input> </fieldset> <row> <panel> <table> <searchString>| savedsearch echo echo="$field1$"</searchString> </table> </panel> </row> </form>
The saved search
echo looks like this:
| stats count | eval echo = "$echo$"
foo in the text field properly returns a value of
foo in the table's
This doesn't appear to work when using it inside a dashboard. If I run: "|savedsearch Perfmon_Processor_ProcessorTime_Total host=CO1*DATCDS*" in the search window I get the expected result.
If I take the same string and paste it into the dashboard not only does the editor not like it, it doesn't work.
|savedsearch Perfmon_Processor_ProcessorTime_Total host=CO1*DATCDS*
You can't pass tokens to saved searches. You have 2 options
1. make the search into inline search - OR -
2. have a postprocess search and filter the result (returned from saved search) in the process process search ..like "|search host=$host$
Thanks for the quick response jayannah. That's disappointing news. The goal of this exercise was to move away from inline searches. The model I wanted to move to was essentially treating 'savedsearches' like SQL stored procedures. Write it once and then let everyone utilize it.
I've got hundreds of developers, testers and analysts all creating dashboards for their little corner of the world. I don't believe it's a good use of their time creating a chart that shows "processor time" since I've already done it, correctly. They should just be able to pick the reports that they want to see in a dashboard and add them to their panels. That way they can focus on presenting the data that's unique to their job.
What this means is that:
1. There will be variations of how the same data is searched and presented
2. If an issue is found in a particular search the fix is going to need to be applied to all of the dashboards I created
The 2nd option you presented isn't feasible. The savedsearch would have to run against all hosts and then filter in the ones that you actually wanted. We've got ~4,500 hosts so that's a non-starter.
I'm going to submit this as a feature request. All that needs to be done is take any inputs defined in the dashboard and make them available to the savedsearch. For example, if there's a $host$ token defined, make $host$ available to the saved search. If the saved search makes use of them, great, if not, no harm done.