Most/More efficient way of counting incomplete transactions?

[the_wolverine]

I'm using events from 2 sourcetypes to determine whether a transaction is complete. Quite simply, if there are 2 events, then transaction is complete. A single event means incomplete transaction. There has got to be a better way than running a transaction and searching for eventcount=1.

[dwaddle]

What field(s) are you using in your transaction command to provide the common value that binds the transaction? If there is a combination of these fields that is entirely unique for the time range of your search, then an approach using stats might make sense, which is where both @melting and @sdaniels are headed.

If it's not that simple, and you're stuck with transaction instead of stats, then you will probably have to continue what you're doing looking for eventcount and it's probably not going to perform well. Your best optimization may be to set startswith and endswith so at least transactions get closed quickly and keeping them out of the way.

[sdaniels]

If you just want to know how many are incomplete couldn't you run a search like this:

... | stats count by TransactionID | where count = 1 | stats count

This should give you the overall count of transactionIDs where there is only one event in a given time range.

[the_wolverine]

If a transactionID existed this would be no problem. In this scenario, I would be creating the transaction from search language.

[melting]

This is doable with lookups. There is a good blog article about how to do this from Alex Raitz:
maintain state

[melting]

I would guess the number of transactions in the lookup is the important factor. If you only store open transactions and that number is relatively small then I would expect this to work.

[the_wolverine]

When dealing with events coming in number in the millions per day, at what point does this lookup file get out of hand?