Splunk sizing: where is the search concurrency information?

[cmeo]

I've been reviewing the information around sizing Splunk installations and it seems to distill--at its simplest--to two key dimensions: data volume and search concurrency. While historical data volumes are relatively easy to get, it seems to be a lot harder to assemble interactive search activity and saved search activity into some kind of picture of overall search concurrency over a time period.

Does anyone know where Splunk hides all the info you'd need to do this? A lot of the wiki entries seem to be out of date; SoS app gives this problem a good college try, but while the scheduled search stuff seems fine, it uses ps and investigates the command line for the interactive stuff which seems a bit random--surely this information is stored elsewhere in Splunk?

Anyway you need all these things (and more of course) to size Splunk properly, and it's fairly strange that you don't seem to be able to get this out of the box. Especially when nearly everyone uses pilot projects to arrive at real sizing...somehow!

[Ledion_Bitincka]

If you're using 6.x you can find that information in Activity (upper right hand corner) >> System Activity >> Search activity overview - or you can get to the raw data using the following search:

index=_internal source=*metrics.log group=search_concurrency "system total" NOT user=* 

[cmeo]

found yet another variant:

| history | timechart span=1d count(search)

different again...so which one do I trust?

[asimagu]

did you try using dc(search) ?

[Ledion_Bitincka]

use/trust metrics.log

[cmeo]

I need history as well as current activity. Trying these two searches at the moment:

index=_audit action=search info=granted search=* NOT "search_id='scheduler" NOT "search='|history" NOT "user=splunk-system-user" NOT "search='typeahead" NOT "search='| metadata type=* | search totalCount>0" | timechart span=1m count(search)

index=_internal source=*metrics.log group=search_concurrency "system total" NOT user=* | timechart span=1m count(_raw)

They are returning results that are different, the second giving counts very much larger than the first. Is there a canonical answer to this question? Unless there is, I'll go with the second and hope for the best...