Can I use n field values as field names for summary indexing?

[warden]

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?

[gkanapathy · Accepted solution]

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

or

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 stats summary.

[warden]

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 🙂