I have an odd situation where the "endswith" transaction is not always being written out by the application so that it can later be paired up with the "startswith" transaction. That means that a given "startswith" transaction is being married up with the wrong unhandled exception.
I can get around the problem if I can read the data backwards. That way I could ensure that I would create a correct transaction with an "endswith" and "startswith" pair. This pair would be ignored and what would be left would be an unhandled exception paired with the correct beginning of the transaction. To do this I need to be able to read the data backwards. Can this be done?
| transaction host startswith=eval(match(_raw,"START]") OR match(_raw,"STARTED]"))
endswith=eval(match(_raw,"END]") OR match(_raw,"ENDED]") OR match(_raw,"unhandled"))
| where NOT match(_raw, "END]") and NOT match(_raw, "ENDED]")
This will pair the unhandled exception with the first START or STARTED of perhaps several that had no corresponding END or ENDED.
Doesn't transaction
do that by default?
This query sets up some dummy data as Splunk would yield it:
| stats count | eval _time = now() | eval key = "exception start start start" | makemv key | mvexpand key | rename key as _raw | streamstats count | eval _time = _time - count
Append this:
... | transaction keepevicted=t startswith="start" endswith="exception"
My results show the most recent start
being paired up with the exception
event.
It IS a rather involved ending expression. I might have something like.
Start
Start
Start
Exception
In this case the exception should be associated with the third Start, not with the first. (This example is obviously simplified.) Transactions that are appropriately paired with Start/End records are pruned out, leaving start-of-transaction and unhandled exceptions.
If I could read the data backwards I would be able to associate the correct Exception with the correct Start.
Does that mean you have a regular ending of a transaction that sometimes is replaced with an unhandled exception in the logs?
You might be able to specify a more complex endswith
condition that catches those as well, do post some sample data for help with that.
You can't actually read in the data in reverse order, but you can perhaps try this before your transaction:
http://answers.splunk.com/answers/1691/how-to-reverse-the-order-of-displayed-events
I know how to reverse displayed data, but that is of no use to me. I simply need to access the data in a "backwards" direction.