I am running a script that, simply put, inserts a record into Splunk for each person that is using space on our storage system. It also includes each user's department. I would like to use summary indexing on this data so that I can track (long-term) each department's usage. The problem? We have over 100 departments. Until now, I have been creating summary-indexed fields by hand. Applying that approach to this problem would yield something like:
storagevol1_department1_numrecords, storagevol1_department1_mbused, storagevol_department2_numrecords . . .
in the field list of the saved search that would be sent to the summary index. Volumes * departments * 2 fields is a lot of typing, and one ugly saved Splunk search.
What I'd like to do is automatically have every combination of volume, qtree, department and numrecords|mbused that shows up in:
stats count(_time) as "numrecords", sum(used_mb) as "mbused" by volume,qtree,department
go into the summary index in such a way that I could use each of those combinations in a timechart in the future. Essentially, I want to use a combination of field values and field names to create new field names.
Am I missing something? Should I be using sistats and focus on separating the combinations of and in the report that pulls from the summary indexed data?
I'm not sure what you're currently doing, but I would simply set the search:
| stats count as numrecords,sum(used_mb) as mbused by volume,qtree,department
to be summarized, and that will do exactly what you want. You'll just wind up with a separate row for each combination, which you would then report on using:
index=summary source="summary search name" | stats sum(numrecords) by department
index=summary source="summary search name" | timechart sum(mbused) by department
It might be a little easier to just summarize instead using:
... | sistats count,sum(used_mb),avg(used_mb) by volume,qtree,department
and your report would then look more like:
index=summary source="sistats summary search" | timechart avg(used_mb)
which would be slightly harder to write with the traditional
While this doesn't exactly answer things, it was very helpful. I was looking to do things the "wrong" way and you set me straight 🙂