In message <[email protected]>,
Risto Vaarandi writes:
>On 03/20/2012 09:54 PM, John P. Rouillard wrote:
>>
>> Hi all:
>>
>> When sec creates a dump file, the input sources are reported as:
>>
>> Input sources:
>> ============================================================
>> /var/log/messages (status: Open, type: regular file, device/inode: 64774/8
>339528, received data: 180797 lines, context: _FILE_EVENT_messages)
>> /var/spool/sec/Control (status: Open, type: pipe, device/inode: 64770/5846
>44, received data: 0 lines, context: CONTROL)
>>
>> would it be possible to get a byte ofset at which SEC is reading put
>> in there as well for "type: regular file".
>>
>> What I am trying to do is see how far SEC has to process to reach the
>> end of the file (aka realtime). Ideally I should be able to ls -l the
>> file and be able to compare that to the reported offset. The
>> difference between the two is how many bytes sec has to process to
>> reach realtime.
>>
>...
>The file position indicator should be easy to implement -- one needs to
>invoke some extra system calls during the dump, which does not add CPU
>overhead to regular rule matching.
Agreed.
>There is one crucial difference
>between the number of processed lines and file position, though. The
>former reflects lines successfully read and processed from a given file.
>However, it is possible that the file position is located beyond the end
>of the last processed line, since SEC implements line buffering layer on
>top of read(2) system calls. For example, we could have a very long line
>for which read(2) hasn't seen a terminating newline yet. Therefore, the
>reported file position does not necessarily mean that all the data
>before it have been processed by SEC -- it merely indicates the data
>have been read (but could still reside in a buffer).
Hmm, maybe add an indication of how many characters are in the line
buffer? Something like:
/var/log/messages (status: Open, type: regular file,
device/inode: 64774/833 9528, received data: 180797 lines,
file position: 321992882 bytes, buffered: 1024 bytes,
context: _FILE_EVENT_messages)
where the number of bytes is reported as buffered? (Also IIUC this
works for both --nojointbuf and --jointbuf as the line buffering layer
is per input stream correct?)
So a backup in processing could be seen in:
file position < length of file
buffered >> the expected length of a single line (i.e.
there are new line delimited lines in the buffer)
> > Which leads me to wonder if some sort
>> of profiling mode could be added to sec that tells me for every rule:
>>
>> how many events are compared to the rule (the current metrics only
>> tell me how many events were matched by the rule including
>> context processing). With this info I can restructure the order
>> to put more expensive/inefficient rules later in processing.
>>
>> how many times an event is processed by a rule. This is sort of the
>> inverse of the stat above, but is a good metric to use to tune
>> rules as reducing the number of event -> rule applications
>> seems to be the best way to reduce processing time.
>>
>> how long on average (in real and cpu second/centiseconds) it takes
>> to process an event against a rule (provides an indication of
>> how efficient the regexp/rule is).
>>
>> I expect this would toss performance through the floor, but I could
>> see this as being a useful offline mode to throw thousands of same
>> events against and use it to tune the ruleset order, regexps etc.
>>
>
>The rest of the ideas need some thought, though, since they add some
>overhead to the main matching loop (even if extra code is not used, one
>still needs to check command line flags if the measuring functionality
>is switched on).
Is there a way in perl to have the compile of the script remove lines?
Sort of like how python optimizes out __debug__ lines if optimization
is requested. That would make the profiler have 0 effect unless
enabled since it would not show up in the perl bytecode.
Maybe a perl source filter (ugly but...) could work? It may require
a second source file though.
http://perldoc.perl.org/perlfilter.html look for
USING CONTEXT: THE DEBUG FILTER
for an idea.
--
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Simple-evcorr-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
