[Nagiosplug-devel] Re: Rewrite of check_log

[Jason Martin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I believe check_log2 uses a state file that has the byte position where 
it last. If the log rotates, the seek to that location will fail and it 
will start from the beginning.

You are correct in that check_log's method of using diff to read only the 
new events is ...interesting. 

- -Jason Martin
Feb 2004, Paul L. Allen wrote:

> Flo Gleixner writes: 
> 
> > I did a half-rewrite of the check_log script.
> 
> Good.  Both check_log and check_log2 are seriously flawed (in my
> opinion).  They do NOT scale well for large logs.  My PHB writes
> stuff that deals with logs and scales badly too, and I beat him over the
> head when it all falls apart and one of our boxes goes into terminal
> CPU overload because of his crude approach to dealing with log events. 
> 
> > - No more diff. It calculates the difference with the difference of the
> >   filesizes and only greps the added lines. This implies:
> > - greatly increased performance for large log files.
> 
> Good.  So what happens when logrotate kicks in?  I think a check_log
> replacement has to retain state: how far it got into the logfile and
> the inode of the logfile (so it can know if the file has been rotated).
> I haven't examined the problem very deeply because right now I don't
> have a need to use check_log.  But those are the two biggest problems
> that occurred to me when I looked at check_log and check_log2 (sorry,
> Ethan, those two just don't come even close to being sensible if I wanted
> to monitor any of our logs - typical maillog size is 40M/day and a "scan
> right the way through to get the latest entry" approach just doesn't
> cut it.) 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.3 (GNU/Linux)
Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/

iD8DBQFAPiCKl2ODWuqVSBMRAl8dAJ9U5YiFI7s1eq/wcrVUbIVjrlvIgACdFrQE
UhBiNVk7ThaTEYQDg7fQoew=
=V7Wx
-----END PGP SIGNATURE-----