Getting the same info out of a summary index that went in.

[Lucas_K]

I have the following search (named : "product groups by severity" ) against some test data that works as expected and is formatted as I require. This search simply groups together alert levels per product_group.

index="test" Product_Group="*" earliest=03/17/2012:0:0:0 latest=04/17/2012:0:0:0 | sistats count(eval(Severity="Critical")) AS Critical, count(eval(Severity="Major")) AS Major, count(eval(Severity="Minor")) AS Minor by Product_Group | sort - num(Critical)

The issue is that because of the time frame takes quite a while to run.

Thus, a scheduled search which populates a summary index was created to improve performance.

The summary index contains entries like this

03/17/2012 00:00:00, search_name="product groups by severity", search_now=1336701540.000, info_min_time=1331902800.000, info_max_time=1334584800.000, info_search_time=1336701541.040, Product_Group=non_production, Severity=Minor, psrsvd_gc=3177, psrsvd_v=1, Critical="Critical",Major="Major",Minor="Minor"

My issue is in trying to get this same format data back when its run against the summary index.

The summary search query as I understand how im supposed to create it (splunk docs) is the same just utilising normal stats commands :

index="summary_test" Product_Group="*" earliest=03/17/2012:0:0:0 latest=04/17/2012:0:0:0 | stats count(eval(Severity="Critical")) AS Critical, count(eval(Severity="Major")) AS Major, count(eval(Severity="Minor")) AS Minor by Product_Group | sort - num(Critical)

However all the values are zeroed out (i'm obviously not supposed to run count/eval against summary data I expect).

This would mean that the summary search isn't correct so I need to do something different right?

If I do the following search I can see the raw data im after.

index="summary_test" search_name="product groups by severity" | table Product_Group, Severity, psrsvd_gc

My question is ... How I do get the right value pairs but how can I get a "like for like" representation utilising the summary search? Its not as per the documentation that you just change the index and then replace the "sistats" command with "stats" command.

I think there is something fundamental about summary searches that i'm missing.

Thanks.

[lguinn2 · Accepted solution]

So here's the deal - I don't think that you can use the eval function in the count command in sistats.

To get what you want, I propose the following populating search:

index="test" Product_Group="*" | sistats count by Product_Group Severity

Run it once an hour or every 5 minutes or whatever interval is appropriate, saving the results in the index "summary_test". Call the search "product groups by severity".

To retrieve the data and run the final search:

index="summary_test" search_name="product groups by severity" | 
stats count by Product_Group Severity

This will give you three "rows" for each product group, one for each severity. If you really need a single line for each product group, do this:

index="summary_test" search_name="product groups by severity" | 
stats count by Product_Group Severity |
eval CriticalX = if(Severity=="Critical",count,0) |
eval MajorX = if(Severity=="Major",count,0) |
eval MinorX = if(Severity=="Minor",count,0) |
stats sum(CriticalX) as Critical sum(MajorX) as Major sum(MinorX) as Minor by Product_Group |
sort -Critical

[Lucas_K]

Thanks. I'll give that a go.

[Lucas_K]

The populating search was the very first search above.

ie.

index="test" Product_Group="*" earliest=03/17/2012:0:0:0 latest=04/17/2012:0:0:0 | sistats count(eval(Severity="Critical")) AS Critical, count(eval(Severity="Major")) AS Major, count(eval(Severity="Minor")) AS Minor by Product_Group | sort - num(Critical)

As I could resolve this I just ended up using the normal stats command and pushing that resulting data to another index and using that as the source of the new faster "summary" search.

Not how it was intended to work ... but it works.

[lguinn2]

What does the populating search look like? By that I mean the scheduled search. I think that the problem may be there...