> > > 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
