hi John, in the 2.7 version there is an alternative for measuring the lag. I've added few lines of code to the dump file creation function which record the size and current read offset for the input file (this is done only for regular files, not FIFOs). As a result, the recorded statistics looks like this:
Input sources: ============================================================ /var/log/messages (status: Open, type: regular file, read offset: 1214299, file size: 1214299, device/inode: 2050/12519, received data: 13 lines, no context set) >From the example above, it is evident that there is no lag, since all available bytes have been successfully read. Nevertheless, if inputs are updated at a high rate, a difference of several kilobytes could be observed. That's because creating the dump file requires extra processing time, and during this time few additional KBs could arrive. In my own environment, I've seen accidental differences of 8-10KB which disappear when a new dump file is created in the next second. However, it is important to know that the read offset is not always reflecting the amount of already processed input data. Since reading from file is done by up to 1KB chunks, these chunks could easily contain several lines. As a consequence, only the first line is matched against rules immediately, while the rest will reside in a buffer for a very short amount of time. Nevertheless, any real lag can be certainly detected by comparing recorded read offsets with file sizes. with kind regards, risto > > On another topic, does anybody have a good method for measuring the > sec lag? I have a single input file (/var/log/messages) and I am > using: > > tail -n 75 /var/log/messages > /tmp/a; > /etc/init.d/sec_rsyslog_master_mon dump | \ > sed -ne '/Content of input buffer/,+101p' | tail -n 75 | \ > comm -13 /tmp/a - | wc -l > > which grabs the last 75 lines in the input file and compares it to the > last 75 lines in sec's buffer. The comm prints lines that exist in the > input file but are not matched by lines in sec's input buffer. Then > the lines are counted. > > This has a few issues with it, but seems to be the most accurate > mechanism I have come up with. Obviously this falls down if you have > multiple input files, separate buffers/file etc. > > Enjoy the new year. > > -- > -- rouilj > John Rouillard > =========================================================================== > My employers don't acknowledge my existence much less my opinions. > > > > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122712 > _______________________________________________ > Simple-evcorr-users mailing list > Simple-evcorr-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users ------------------------------------------------------------------------------ Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 _______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
