Databases Reference
In-Depth Information
Let's step through the procedure to set up summary searches as follows:
1.
Save the query using sistats .
sourcetype=impl_splunk_gen
| sistats count max(req_time) avg(req_time) min(req_time) by
user
2.
Set the times accordingly, as we saw previously in the Populating summary
indexes with saved searches section. See the How latency affects summary queries
section for more information.
3.
Build a query that queries the summary index, as we saw previously in the
Using summary index events in a query section. Assuming we saved this query
as testing sistats , the query would be: index="summary_impl_splunk"
search_name="testing sistats" .
4.
Use the original stats function against the results, as follows:
index="summary_impl_splunk" search_name="testing sistats"
| stats count max(req_time) avg(req_time) min(req_time) by user
This should produce exactly the same results as the original query.
The si* variants still seem somewhat magical to me, but they work so well that it
is in your own best interest to dive in and trust the magic. Be very sure that your
functions and fields are a subset of the original!
How latency affects summary queries
Latency is the difference between the time assigned to an event (usually parsed from
the text) and the time it was written to the index. Both times are captured, in _time
and _indextime , respectively.
This query will show us what our latency is:
sourcetype=impl_splunk_gen
| eval latency = _indextime - _time
| stats min(latency) avg(latency) max(latency)
In my case, these statistics look as shown in the following screenshot:
 
Search WWH ::




Custom Search