It is great to hear that everything is working properly :) kind regards, risto
Kontakt Spelta Edoardo (<edoardo.spe...@beta80group.it>) kirjutas kuupäeval N, 16. märts 2023 kell 15:39: > 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
