Databases Reference
In-Depth Information
Scheduling the generation of dashboards
As we stepped through the wizard interface to create panels, we accepted the default
value of
Run search each time dashboard loads
. If we instead select
Run scheduled
search
, we are given a time picker.
When the dashboard is loaded, the results from the last scheduled run will be used.
The dashboard will draw as quickly as the browser can draw the panels. This is
particularly useful when multiple users use a dashboard, perhaps in an operations
group. If there are no saved results available, the query will simply be run normally.
Be sure to ask yourself just how fresh the data on a dashboard needs to be. If you are
looking at a week's worth of data, is up to one-hour-old data acceptable? What about
four hours old? 24 hours old? The less often the search is run, the fewer resources
you will use, and the more responsive the system will be for everyone else. As your
data volume increases, the searches will take more time to complete. If you notice
your installation becoming less responsive, check the performance of your scheduled
searches in the
Jobs
or the
Status
dashboards in the
Search
app.
For a dashboard that will be constantly monitored, real-time queries are probably
more efficient, particularly if multiple people will be using the dashboard. New
in Splunk 4.3, real-time queries are first backfilled. For instance, a real-time query
watching 24 hours will first run a query against the previous 24 hours and then add
new events to the results as they appear. This feature makes real-time queries over
fairly long periods practical and useful.
Editing the XML directly
First let me take a moment to tip my hat to Splunk for the new dashboard editor
in Splunk 4.3. There are only of a couple of reasons why you would still need to
edit simplified XML dashboards: forms and post-processing data. I predict that
these reasons will go away in the future as more features are added to the
dashboard editor.
Search WWH ::
Custom Search