topic Re: How to track maximum overlapping transactions? in Splunk Search

How to track maximum overlapping transactions?

peterd — Fri, 22 Aug 2014 18:18:21 GMT

I maintain a set of charts that keep track of REST APIs which create and delete resources (documents). In this particular case, tracking the maximum number of "open" documents, where a PUT creates the resource, and DELETE removes the resource. The search i attempted was:

uri_path=*docs* (method=PUT OR method=DELETE) |   
eval s=case(method=="PUT",1,method=="DELETE",-1) |
transaction documentid maxspan=24h 
startswith="method==PUT" endswith="method=DELETE" connected=t unifyends=t keepevicted=true | 
streamstats sum(s) as c by clientid | 
eventstats max(c) as mcc by clientid |
stats  max(mcc) as MaxOpenDocs by clientid

however, MaxOpenDocs is always 0 (which is clearly wrong). My initial thought was to use accum, but it lacks a by clause. Any recommendations? Clearly I am missing something.

Re: How to track maximum overlapping transactions?

martin_mueller — Fri, 22 Aug 2014 19:02:19 GMT

Try this:

base search | transaction documentid ... | concurrency duration=duration

That'll use the duration field produced by the transaction command along with the start time stamp and compute a concurrency field. I think that field is what you're looking for.

http://docs.splunk.com/Documentation/Splunk/6.1.3/SearchReference/concurrency

Re: How to track maximum overlapping transactions?

peterd — Fri, 22 Aug 2014 19:10:41 GMT

Thanks, but the concurrency command calculates the number of simultaneous event start times. According to the documentation:

"Concurrency is the number of events that occurred simultaneously at the start time of the event, not the number of events that occurred during any overlap."

.. and i need that "overlap" count. e.g. the maximum number of overlapping transactions by clientid.

Re: How to track maximum overlapping transactions?

martin_mueller — Fri, 22 Aug 2014 20:39:06 GMT

I see. Well, in your original query you're always getting a zero because the transaction command bunches each +1 event together with a -1 event, cancelling each other out. Your approach basically calculates the transaction manually, so you should leave out the transaction command:

base search | eval +1, -1 | streamstats | stats

I left out the eventstats because calculating max(max(c)) doesn't make it any "maximumer".