Hi,
i did the same test you did, just with an error in the pattern matching 😊
it’s beautifully working now!
Thanks a lot for the help, it was very precious!
Best regards,
M
Da: Risto Vaarandi <risto.vaara...@gmail.com>
Inviato: mercoledì 15 marzo 2023 19:20
A: Spelta Edoardo <edoardo.spe...@beta80group.it>
Cc: simple-evcorr-users@lists.sourceforge.net
Oggetto: Re: [Simple-evcorr-users] Duplicate suppression and rearming
1. As long as we exclude the longer window expiration case (so we just want
to suppress events for 10 secs), why you suggest to use two Single rules
instead of a SingleWithSuppress ?
I’m referring to these rules:
type=Single
ptype=RegExp
pattern=event_(\w+)
context=!SUPP_$1
desc=react to event $1 and set up suppression
action=write - We have observed event $1; create SUPP_$1 10
type=Single
ptype=RegExp
pattern=event_(\w+)
context=SUPP_$1
desc=do not react to event $1 and only update its suppression context
action=set SUPP_$1 10
1. Does SingleWithSuppress use a sliding window ? According to my latest
tests it does not, so it should be equivalent to your two Single
rules..shouldn’t it ?
you are correct that the SingleWithSuppress rule does not use a sliding
window. In contrast, the above two rules implement the sliding suppression
window.
1. For the more complex scenario, when you introduced also a MAXLIFE
context of 60 secs, so i’m referring to:
type=Single
ptype=RegExp
pattern=event_(\w+)
context=!SUPP_$1
desc=react to event $1 and set up suppression
action=write - We have observed event $1; \
create SUPP_$1_MAXLIFE 60 ( delete SUPP_$1 ); \
create SUPP_$1 10 ( delete SUPP_$1_MAXLIFE )
type=Single
ptype=RegExp
pattern=event_(\w+)
context=SUPP_$1
desc=do not react to event $1 and only update its suppression context
action=set SUPP_$1 10
..as far as i can see, the shortest 10secs context will always expire first,
thus deleting the MAXLIFE as well…so in the end this behaves just like the
longer context does not exist at all. It seems equivalent to your rules in
bullet 1), am i wrong ?
the lifetime of SUPP_$1 context is extended for another 10 seconds on each
matching event, so the SUPP_$1 context can actually have a longer lifetime than
SUPP_$1_MAXLIFE.
I’ve been generating identical events every two seconds, and with those two
rules i get 1 line every 10 seconds…instead i would expect to get one every 60
seconds…because i expected the 10sec window to be constantly sliding thus
suppressing everything until the 60 seconds windows expires and basically reset
everything.
What am i missing ?
May I ask what is the format of the events you are generating, and do they all
look the same (for example, event_A)?
I have tested the ruleset with events "event_A" that are generated after every
5 seconds with the following command line:
while true; do echo event_A >>test.log; sleep 5; done
Also, before starting the above command line, I executed sec with the following
command line that monitors test.log for incoming events. In addition, this
command line writes a detailed debug log to sec.log:
sec --conf=test.sec --input=test.log --log=sec.log
Here is the content from sec.log:
Wed Mar 15 19:56:28 2023: SEC (Simple Event Correlator) 2.9.1
Wed Mar 15 19:56:28 2023: Reading configuration from test.sec
Wed Mar 15 19:56:28 2023: 2 rules loaded from test.sec
Wed Mar 15 19:56:28 2023: No --bufsize command line option or --bufsize=0,
setting --bufsize to 1
Wed Mar 15 19:56:28 2023: Opening input file test.log
Wed Mar 15 19:56:28 2023: Interactive process, SIGINT can't be used for
changing the logging level
Wed Mar 15 19:56:31 2023: Writing event 'We have observed event A' to file '-'
Wed Mar 15 19:56:31 2023: Creating context 'SUPP_A_MAXLIFE'
Wed Mar 15 19:56:31 2023: Creating context 'SUPP_A'
Wed Mar 15 19:56:36 2023: Changing settings for context 'SUPP_A'
Wed Mar 15 19:56:41 2023: Changing settings for context 'SUPP_A'
Wed Mar 15 19:56:46 2023: Changing settings for context 'SUPP_A'
Wed Mar 15 19:56:51 2023: Changing settings for context 'SUPP_A'
Wed Mar 15 19:56:56 2023: Changing settings for context 'SUPP_A'
Wed Mar 15 19:57:01 2023: Changing settings for context 'SUPP_A'
Wed Mar 15 19:57:06 2023: Changing settings for context 'SUPP_A'
Wed Mar 15 19:57:11 2023: Changing settings for context 'SUPP_A'
Wed Mar 15 19:57:16 2023: Changing settings for context 'SUPP_A'
Wed Mar 15 19:57:21 2023: Changing settings for context 'SUPP_A'
Wed Mar 15 19:57:26 2023: Changing settings for context 'SUPP_A'
Wed Mar 15 19:57:31 2023: Changing settings for context 'SUPP_A'
Wed Mar 15 19:57:32 2023: Deleting stale context 'SUPP_A_MAXLIFE'
Wed Mar 15 19:57:32 2023: Deleting context 'SUPP_A'
Wed Mar 15 19:57:32 2023: Context 'SUPP_A' deleted
Wed Mar 15 19:57:32 2023: Stale context 'SUPP_A_MAXLIFE' deleted
Wed Mar 15 19:57:36 2023: Writing event 'We have observed event A' to file '-'
Wed Mar 15 19:57:36 2023: Creating context 'SUPP_A_MAXLIFE'
Wed Mar 15 19:57:36 2023: Creating context 'SUPP_A'
As you can see, the event "event_A" that appeared at 19:56:31 triggered a
notification message, and also, suppression contexts were set up. Also, after
every 5 seconds debug messages "Changing settings for context 'SUPP_A'" appear.
These messages reflect the execution of the 'set SUPP_A 10' action when the
event "event_A" appears. Finally, at 19:57:32 (61 seconds after 19:56:31) the
context SUPP_A_MAXLIFE becomes stale, and when this context is going through
the deletion process, the context SUPP_A is also deleted (see the "Context
'SUPP_A' deleted" debug message). The disappearance of both contexts ends the
event suppression process, and when the next event "event_A" appears at
19:57:36, a notification is again printed to standard output.
Did you generate events with the *same* suffix in real-time and provided them
to SEC in the fashion as described above? If you want to debug the ruleset
interactively in a quick way, you can also use smaller timeouts than 10 and 60
seconds, and monitor events from standard input with the --input=- command line
option. This allows you to type input events from the keyboard and observe what
kind of SEC debug messages are produced in a terminal window.
Hope this helps,
risto
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
