Hi, an event load of 52 events per minute very modest one, because sec can
handle thousands of events per second. As I understand, you have already
verified that your rules are matching events? If yes, the only problem I
can see are issues with writing the events into pipe that sec is reading.
Does the process which writes the events produce a detailed log about its
activities, so that you can be sure events were actually written? Also, in
which mode events are written to the pipe - blocking or nonblocking? When
pipes have been opened in nonblocking mode by the writer, events can get
lost under some circumstances (e.g. the pipe becomes full during an
occasional event burst).
Kind regards, risto
On Jun 10, 2014 6:40 PM, "mindman101" <mindman...@zoho.com> wrote:
> Hello list.
>
> I email you to ask for your help and advice with an issue we have
> currently with a deployment of SEC. We´ve worked with SEC about two years
> without any problem, at least detected. At my work, SEC makes part of a
> complex events management system based on open source tools such as NET-
> SNMP and SNMPTT. Maybe with the growth of the amount of equipment sending
> SNMP traps to this system, it has started to appear an issue related with
> events that haven´t been processed by the system in mention. The question
> is: in which part of the system is happening the malfunction? This issue is
> new, which shows that the process seems to be well designed and something
> is happening with the input of the black box!
>
> I wanna present you this system, at least logically, (illustration
> attached) in which events are processed by different instances or modules.
> The operation of each module is registered either in logs or by monitoring,
> which is the pipe case.
>
> In these days we´ve registered two abnormal situations in which events,
> that arrived to the server via SNMP, weren´t registered in the database of
> the system. The rules installed in the SEC files (.confs) were verified Ok
> in the past and one of the suggestions was the format in which the SNMP
> events were arriving to the server. For this reason, we were looking for
> the events related with these situations, which were found processed in the
> logs of 1. snmptrapd, 2. snmptt, 3. PERL Scripting, 4. Pipe. But when we
> were going to look for the respective processing by SEC rules in sec.log,
> we don’t find any registry about that. As I told you, the rules installed
> in the SEC files (.confs) were verified Ok in the past and we decided to
> execute SEC by console with single events one by one and the output shows
> an execution congruent with the nature of the rules and their design. We
> don’t know what´s happen with the SEC app operating in an automatic
> fashion, maybe could be the load that SEC supports or the consumption of
> server resources from SEC, or the capacity of the app. We´ve been reviewing
> SEC´s manual looking information related with the max events load capacity
> of a SEC deployment, the way to increase the consumption of server
> resources by SEC or the reason for which SEC is not processing events that
> should be processed correctly. The events load that is sent to SEC by means
> of the pipe is about 52 events per minute in average matching rules type
> PairWithWindow with time windows near 30 seconds (to control flapping
> situations in the network). We appreciate your help and advice in order to
> solve this situation.
>
> Incidently, this is execution command of SEC, running as a daemon:
>
> /usr/bin/perl –w /usr/sbin/sec
> --conf=/opt/sec/sec-2.7.4/configs/Controlv1.conf
> --conf=/opt/sec/sec-2.7.4/configs/Controlv2.conf
> --conf=/opt/sec/sec-2.7.4/configs/Controlv3.conf
> --conf=/opt/sec/sec-2.7.4/configs/Controlv4.conf
> --input=/opt/sec/sec_in.pipe --input=/opt/sec/syslog.pipe
> --log=/opt/sec/sec-2.7.4/sec.log --detach -p /var/run/sec.pid
>
>
> Thanks in advance.
>
> John Mendez
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Simple-evcorr-users mailing list
> Simple-evcorr-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>
>
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
