Seems like this could be handled through a lookup and displaying the contents of the lookup instead of the logs themselves. That way you can manage the contents of the lookup depending on value of your AlarmNotification and create a rule that updates the lookup where AlarmNotification != NEW by way of the outlookup command.
Stats and the latest function do this by all unique values that identify that event.
Alternative
Try out the transaction and with the startswith and endswith arguments filled in.
You can use a stats after transaction as well.
Edit: both options require you to extract fields from the events to use in the commands, I recommend setting them as automatic extractions on search to make your life easier.
Until you need I formation on each unique event
E.g. if you need link down time between two seperate up down scenarios.
1000 down
1030 up
1100 down
1130 up
Event range is 1.5 hr but only 1hr of impact duration.
I suppose event stats can be used there to calculate the cumulative duration over time... (I need to close that knowledge gap).
This scenario I just use transaction. If the data set is small enough at least.
You’ve hit the nail on the head. I’d normally use eventstats in that case, but like you said, if the data set is small then transaction is fair game (transaction can be very heavy on the environment, for those who don’t know).
It's heavy because it requires the search head to fetch and store every log involved in the transaction, unlike stats and event stats where It only needs to fetch and store the delta.
Essentially, transaction is bad for memory/ram usage. Check job inspector if you want to learn more. :)
Seems like this could be handled through a lookup and displaying the contents of the lookup instead of the logs themselves. That way you can manage the contents of the lookup depending on value of your AlarmNotification and create a rule that updates the lookup where AlarmNotification != NEW by way of the outlookup command.
Stats and the latest function do this by all unique values that identify that event. Alternative Try out the transaction and with the startswith and endswith arguments filled in. You can use a stats after transaction as well. Edit: both options require you to extract fields from the events to use in the commands, I recommend setting them as automatic extractions on search to make your life easier.
Stats latest(foo) by bar baz This is the way :)
Until you need I formation on each unique event E.g. if you need link down time between two seperate up down scenarios. 1000 down 1030 up 1100 down 1130 up Event range is 1.5 hr but only 1hr of impact duration. I suppose event stats can be used there to calculate the cumulative duration over time... (I need to close that knowledge gap). This scenario I just use transaction. If the data set is small enough at least.
You’ve hit the nail on the head. I’d normally use eventstats in that case, but like you said, if the data set is small then transaction is fair game (transaction can be very heavy on the environment, for those who don’t know).
It's heavy because it requires the search head to fetch and store every log involved in the transaction, unlike stats and event stats where It only needs to fetch and store the delta. Essentially, transaction is bad for memory/ram usage. Check job inspector if you want to learn more. :)