Databases Reference
In-Depth Information
The main thing to remember here is that we cannot make a graph more detailed than the
schedule of our populating query . In this case, the populating query uses a span of one
hour. 1 hour is granular enough for most daily reports, and certainly fine for weekly
or monthly reports, but it may not be granular enough for an operations dashboard.
The following are a few other interesting queries you could make with this simple
set of data:
index="summary_impl_splunk" search_name="summary - count by user"
| stats avg(count) as "Average events per hour"
The previous code snippet tells us the average number of events per slice of time,
which we know is an hour. Adding bucket and another stats command, we can
calculate for a custom period of time, as follows:
index="summary_impl_splunk" search_name="summary - count by user"
| bucket span=4h _time
| stats sum(count) as count by _time
| stats avg(count) as "Average events per 4 hours"
This query would give us the user with the maximum number of events in a given
hour, and the hour it happened in:
index="summary_impl_splunk" search_name="summary - count by user"
| stats first(_time) as _time max(count) as max by user
| sort -max
| head 1
| rename max as "Maximum events per hour"
Using sistats, sitop, and sitimechart
So far we have used the stats command to populate our summary index. While this
works perfectly well, the si* variants have a couple of advantages:
• The remaining portion of the query does not have to be rewritten. For
instance, stats count still works as if you were counting the raw events.
stats functions that require more data than what happened in that slice of
time will still work. For example, if your time slices each represent an hour, it
is not possible to calculate the average value for a day using nothing but the
average of each hour. sistats keeps enough information to make this work.
 
Search WWH ::




Custom Search