Let's say I have a summary indexing search, called "my_si_search", that's defined like this:
<code> eventtype="performance-event" | sistats avg(seconds) median(seconds) stdev(seconds) p5(seconds) by stats_type </code>
So my final report uses a search like this:
<code>index=summary source=my_si_search | stats avg(seconds) median(seconds) stdev(seconds) p5(seconds) by stats_type </code>
Let's say I created this summary index search months ago, and now I also want to add to add
p95(seconds) to my final stats report. How do I know what this will work with my previously created summary indexed events? When I look at the raw events generated by the
sistats search, it appears that the information doesn't change by simply adding
p95(seconds). So it seems like I don't even need to change my si search at all, is that correct?
Is there any detailed docs/wiki pages out there that help explain the mapping between various
si* stats functions and what all corresponding stats functions can be used based on that information? Certainly planning ahead as much as possible would always be recommended, but that's not always possible.
It appears that adding
range(seconds) generates the same two fields (
nx) that would be added by using both
max(seconds). This makes sense, since range is defined by min and max; but other situations are not as straight forward.
The documentation generally seems geared towards the idea that you build your singular stats-based search they way you want it, then you just swap out the "stats" command with the "sistats" command, save it, schedule it, and point your original search to use the summary index results instead of from your main index (or wherever), and your done. This approach certainly works, but it really doesn't fully capture the complexity of most summary index situations I've encountered. Generally speaking, if I'm going to the effort of creating a summary index event, then I'm probably going to use that as the source for more than one search/report. And generally, I don't start with my final search/report and then convert it into a summary index generating (
si* prefixed) search, instead I usually start with thinking though what I want to summarize (what all stats function for which fields and what fields to use for grouping). And only once I've created my summary indexing search do I build my final saved searches / reports. Perhaps this is the wrong way to approach things, but it seems have been working well; but I'm open to other ideas.
min and max in summary index 0 Answers
SISTATS vs STATS 2 Answers