> Hi all:
>
> I am trying to set up some analysis rules for file opens/access per
> hour. If it exceeds a particualr threshold I alert. Simple enough
> except that directory access also generates the same events that look
> like file access. So I have an event stream that looks like:
>
> open p1
> opendir p1
> open p2
> open p3
> opendir p3
> open p4
> open p5
> open p5
> open p6
> opendir p6
>
> where p1-p6 are some file paths. p1, p3 and p6 are actually
> directories and I can tell that because after I get the open event, I
> get an opendir event with the same path.
>
> So here are the simplified rules I am using:
>
> desc = $1 a file?
> type=PairWithWindow
> ptype= regexp
> rem = $1 = path
> pattern= open (.*)
> rem = don't match this rule if it's a generated event
> context = ! _INTERNAL_EVENT
> rem = opendir not found so it's a file; label and submit
> action = event isfile $0
> desc2 = find opendir indicating it's a directory
> ptype2 = regexp
> pattern2= opendir (.*)
> rem = for debugging write it as a directory
> action2 = write - %1 is a directory
> window = 1
>
> desc = detect excessive number of file open/access
> type = EventGroup
> ptype = regexp
> rem = $1 = file
> pattern= ^isfile.*open (.*)
> context= ! filename_accessed_$1
> action = write excessive files accessed last is $0; report \
> files_accessed /bin/cat
> count = add files_accessed $1; alias files_accessed
> filename_accessed_$1
> end = delete files_accessed
> window=3600
> thresh=50
>
> Now this works, except I expect that the files_accessed context should
> contain
>
> p2
> p4
> p5
>
> I.E. the filenames should have the same order as they first appeared
> in the input. However using sec 2.7.3 I get
>
> p2
> p5
> p4
>
>
> Which matches the order in which the events are logged as being
> created. Am I wrong to expect the events to occur in order that the
> input events were seen?
>
hi John,
what is the timespan between p4 and p5? If they happen within the same
second, the PairWithWindow event correlation operations are started within
the same second for them, which also implies that the operations end within
the same second. Since all time measurements are done with a precision of a
second inside the code, the order in which "isfile open" synthetic events
appear is not determined. Internally, the hash of event correlation
operations is processed in the order returned by Perl keys(), and the
expired operations are treated in this order.
kind regards,
risto
>
> This is consistent with the p5 PairWithWindow correlation finishing
> before p4, but it is not what I expected.
>
> --
> -- rouilj
> John Rouillard
> ===========================================================================
> My employers don't acknowledge my existence much less my opinions.
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> Simple-evcorr-users mailing list
> Simple-evcorr-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
