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