I am having an issue with search using transaction starts/endswith. The information I am pulling counts transactions that are not immediately after each other or in sequence.
search | transaction startswith="LSP_DOWN" endswith="LSP_UP" | eval DownTime=_time | eval UpTime=_time+duration | eval DownTime=strftime(DownTime, "%D:%H:%M:%S") | eval UpTime=strftime(UpTime, "%D:%H:%M:%S") | eval duration=tostring(duration, "duration") | table LSP DownTime UpTime duration
Sample result shown below for one LSP (out of >10k LSPs), where the second line shouldn't be counted as a completed transaction:
LSPA 07/19/16:16:54:22 07/19/16:16:54:28 00:00:06
LSPA 07/10/16:05:08:48 07/31/16:06:03:48 21+00:55:00
LSPA 07/09/16:04:46:11 07/09/16:04:46:19 00:00:08
Sequence of events:
07/31/16:06:03:48 LSP UP
07/19/16:16:54:28 LSP UP
07/19/16:16:54:22 LSP DOWN
07/10/16:05:08:48 LSP DOWN
07/09/16:04:46:19 LSP UP
07/09/16:04:46:11 LSP DOWN
Based on the above, the result should discard 07/31/16:06:03:48 LSP UP
& 07/10/16:05:08:48 LSP DOWN
as they are incomplete events. maxopenevents=2
or maxopentxn=2
fixes the issue, however, they remove a lot of other valid "complete" transactions.
See Descending time order required
Strangely, I've also found that evals after the transaction can scramble the results.
Still looking for an answer...
Try adding unifyends= true to your transaction command.
I've tried each with unifyends=true, maxevents=2, maxopentxn=2, maxopenevents=2 and also combinations of them.
I would suggest one of these options...
... | transaction startswith="LSP_DOWN" endswith="LSP_UP" maxevents=2 | ...
OR
.... | rex "(?<state>UP|DOWN)" | autoregress state as next_state | where state!=nextstate | delta _time as duration | where state="DOWN" | eval DownTime=_time | eval UpTime=_time+duration | eval DownTime=strftime(DownTime, "%D:%H:%M:%S") | eval UpTime=strftime(UpTime, "%D:%H:%M:%S") | eval duration=tostring(duration, "duration") | table LSP DownTime UpTime duration
Thank you for the response, the maxevents=2 suggestion produced the same result as not having it there.
The second suggestion produced the same result except that it switches the DownTime with UpTime starting from the second line and only computed the duration of the first line, the others showed with no duration value.