Gentlemen, I'd like enhance syslog-ng with some features in order to get rid of some log rotation scripts. For some of our systems, we log on a centralised system, but also store the logs locally. These logs only need limited availability, say a week or so. The file() destination currently is already able to use the target $WEEKDAYS (which is undocumented, btw), but in that case, logs from both Jan 17 and Jan 24 are logged in messages.Thu.log Therefore, I'd like to add a new option clear_old(X) which removes a logfile with a timestamp older than X days prior to writing the new message to that file. (default should be 0 (=never), which means that for a disabled feauture only one C 'if' statement additional overhead is caused) But I can imagine that people also wants to set a max size on a logfile. E.g. to be able to compress it afterwards, or for simple log rotation, like: file('/var/log/mesages' max_size_old(200, 'gzip')) will rename the existing 200 kB file to /var/log/messages.old and then run 'gzip /var/log/messages.old' Maybe it is better to add a new destination rotatedfile(), maybe it's better to do something else... I'd to know wheter everyone agrees that these features are a good idea, and that the proper approach is taken to keep the configurationfile syntax simple. Groetjes, Klaas van Gend
Hi! On Thu, Jan 24, 2002 at 10:03:59AM +0100, klaas.vangend@philips.com wrote:
I'd like enhance syslog-ng with some features in order to get rid of some log rotation scripts. One thing that seems particularly useful to me is rotating the logs after a certain amount of time, 14 days for example. But in my opinion it is not necessary to implement this feature in syslog-ng; here's what I do:
I let syslog-ng write all its logs to a directory named "current", which is in fact a symlink to a directory named, for example, "2002-01-24". I rotate the logs with a script that is run by cron. This script creates a new directory and changes the "current"-symlink. Then it sends a SIGHUP to syslog-ng, which makes it reopen all the logfiles in the new directory. Then my script compresses the old logfiles. You could very easily do something similar to solve your problem, but if you want to get rid of rotation scripts, as you said, then this is probably not what you want.
I'd to know wheter everyone agrees that these features are a good idea, and that the proper approach is taken to keep the configurationfile syntax simple. Well, I believe that it is difficult to implement something that gives you the same flexibility that you have with log rotation scripts. Perhaps you youd create a destination driver that can rename the logfile, open a new one and run a specified script when some condition occurs? Or you can run a script based on the return code of another script. No, that sucks too. The more I think of it, the more I believe that my log rotation scripts aren't that bad... :-)
Greetings Gert
klaas.vangend@philips.com on Thu, Jan 24, 2002 at 10:03:59AM +0100: Hi Klaas,
I'd to know wheter everyone agrees that these features are a good idea, and that the proper approach is taken to keep the configurationfile syntax simple.
you can achieve the functionality you are asking for if you use date- extensions to your files ($YEAR$MONTH$DAY) and run one or two very simple commands from cron like find /var/log -mtime +1 -exec gzip -9 {} \; find /var/log -mtime +7 -exec rm -f {} \; I have to say that I run an additional script to extract logfile X of host Y from the log repository, so I don't really have to deal with those funny filenames anymore. I don't have a problem using cron. From your suggestions, the only one that I would agree is required or at least really good to have, is simple rotation by filesize using numeric extensions, where one could specify how big a logfile can be and how many .[0-9]'s backups should be made (the oops proxy server does this nicely). I would still leave compression and deletion to cron. Regards, -- ____ ____ / _/| - > Gregor Binder <gb@(rootnexus.net|sysfive.com)> | / || _\ \ \__ Id: 0xE2F31C4B Fp: 8B8A 5CE3 B79B FBF1 5518 8871 0EFB AFA3 E2F3 1C4B
participants (3)
-
Gert Menke
-
Gregor Binder
-
klaas.vangend＠philips.com