On Fri, 24 Sep 1999, Russell Nelson wrote:
> [EMAIL PROTECTED] writes:
> > Anand Buddhdev wrote:
> >
> > > Request to DJB: time-based logging in multilog would be very useful to
> > > many people. Please consider it as an option besides size-based
> > > rotation, somewhat like FreeBSD's newsyslog. I do understand that
> > > time-based logging could fill up a disk, but that's a risk an end-user
> > > can take themselves.
> >
> > Both features could be combined to get the best of both.
>
> Nope. How do you deal with too many log entries in too short a period
> of time? If you base it on size, you lose log entries. If you base
> it on time, you run the risk of filling up the disk space, and losing
> something else.
>
> Time-based logging doesn't solve any serious problem, since you can
> pull the log file entries out of multiple files very easily. The name
> of the file has the time of the first entry, and the timestamp of the
> file has the time of the last entry. You want perl code? I've got it.
I've been looking at this issue too. While I think that time based
logging would be good, (and the only problem I can see is running out
of disk space) we don't have it yet.
I'm experimenting with something like the following
supervise -r dir process | accustamp | mrtg_logger | cyclog $LOG
The mrtg_logger is simple perl code that takes STDIN and spits it straight to
STDOUT. It also does some stats gathering and every 5 mintes writes
the details to a log file and calls mrtg. The mrtg config file simply
cats the file:
Target[pop3d]: `cat /var/log/pop3d/mrtg.log`
So far I'm logging internal/external pop3d and smtpd connections on a
test box. Next thing to look at is one to run matchup on the input and
extract details from that.
The only problem I can see with this method is that if the system dies
4 minutes 59 seconds into the current cycle, and is restarted, you'll
lose the mrtg stats for those 4 minutes 59 seconds. cyclog will still
have them.
The reson I'm doing it this way is that my log files are reasonably
large (8Mb per day) and groking a big file every 5 minutes to extract
a small section is loading up the system a bit too much.
Regards
Peter
----------
Peter Samuel [EMAIL PROTECTED]
Technical Consultant or at present:
eServ. Pty Ltd [EMAIL PROTECTED]
Phone: +61 2 9206 3410 Fax: +61 2 9281 1301
"If you kill all your unhappy customers, you'll only have happy ones left"
