hi Eli, all data structures created by user are kept in a dedicated namespace main::SEC, in order to avoid clashes with variables in sec code. That applies to all Perl code written by user (such as code used for PerlFunc patterns, lcall actions, etc.).
As a side note -- if there is a special need to access sec internal data structures, it can be done by referring to main:: namespace. The "Perl Integration" section of the official documentation ( http://simple-evcorr.github.io/man.html#lbBB) contains more detailed discussion on namespaces with a relevant example. Hope this helps, risto Kontakt Kagan, Eli (<eli.ka...@dxc.com>) kirjutas kuupäeval N, 20. detsember 2018 kell 20:38: > Thanks Risto. I’ll give it a try. > > > > Are you keeping user defined perl variables in a separate namespace? > > > > -- ek > > > > *From:* Risto Vaarandi <risto.vaara...@gmail.com> > *Sent:* Tuesday, December 18, 2018 1:45 PM > *To:* Kagan, Eli <eli.ka...@dxc.com> > *Cc:* simple-evcorr-users@lists.sourceforge.net > *Subject:* Re: [Simple-evcorr-users] list of suppress events > > > > hi Eli, > > > > if you would like to have regular expressions stored in an external file > and load them at startup and restarts, you could use the following ruleset. > The first rule loads patterns from a file when sec is started or has > received HUP or ABRT signal. The rule assumes that each line contains a > regular expression, compiles these expressions and stores them into the > array @plist. The second example rule compares an input line with regular > expression patterns from @plist, producing a match if any of the patterns > matches: > > > > type=Single > ptype=RegExp > pattern=^(SEC_STARTUP|SEC_RESTART|SEC_SOFTRESTART)$ > context=SEC_INTERNAL_EVENT > desc=load suppress patterns > action=lcall %o -> ( sub { @plist = (); \ > if (!open(FILE, "patterns.txt")) { return 0; } \ > my(@lines) = <FILE>; close(FILE); chomp(@lines); \ > @plist = map { qr/$_/ } @lines; return scalar(@plist); } ); \ > if %o ( logonly %o patterns loaded ) else ( logonly No patterns > loaded ) > > > type=Suppress > ptype=PerlFunc > pattern=sub { foreach $p (@plist) { if ($_[0] =~ $p) { return 1; } } > return 0; } > > > > Since both the PerlFunc pattern and regular expressions are compiled > before usage, their evaluation does not involve any extra overhead. In > fact, when comparing the performance of a list of five regular expression > patterns against five Suppress rules on 1 million non-matching input events > on my laptop, I observed an external list being about 10% faster. However, > the actual performance of both approaches depends heavily on input events > and patterns, so I would recommend to benchmark the above ruleset vs > Suppress rules on your log data. > > > > kind regards, > > risto > > > > > > > > Kontakt Kagan, Eli (<eli.ka...@dxc.com>) kirjutas kuupäeval T, 18. > detsember 2018 kell 19:34: > > Howdy, > > > > I’d like to have a separate file containing a list of regex patterns to > suppress. That is, instead of creating a multitude of Suppress events for > each patter I would like to have a PerlFunc Suppress rule that would use an > external list. Ideally that list should be loaded at startup. > > > > Is there a simple way to create something like that and if so what the > performance impact would be versus generating individual suppress rules > with a config script? > > > > Thanks, > > Eli > > > > DXC Technology Company -- This message is transmitted to you by or on > behalf of DXC Technology Company or one of its affiliates. It is intended > exclusively for the addressee. The substance of this message, along with > any attachments, may contain proprietary, confidential or privileged > information or information that is otherwise legally exempt from > disclosure. Any unauthorized review, use, disclosure or distribution is > prohibited. If you are not the intended recipient of this message, you are > not authorized to read, print, retain, copy or disseminate any part of this > message. If you have received this message in error, please destroy and > delete all copies and notify the sender by return e-mail. Regardless of > content, this e-mail shall not operate to bind DXC Technology Company or > any of its affiliates to any order or other contract unless pursuant to > explicit written agreement or government initiative expressly permitting > the use of e-mail for such purpose. --. > > _______________________________________________ > Simple-evcorr-users mailing list > Simple-evcorr-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users > >
_______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
