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.
--Eric
... View more