On 6/28/06, Peter Samuelson <email@example.com> wrote:
> [Madan U Sreenivasan]
> > Or how about generating a log-file name by appending the date/time
> > stamp, and once it reaches a specific (configured) size, open a new
> > file with another generated name?
> That's pretty nonstandard. The standard thing to do on Unix is to let
> the administrator configure the log file name, and have a way to close
> and reopen the log file, then let the admin and her cron jobs handle
> everything else. What format would you want for the log time stamp,
> anyway? Obviously some form of ISO-8601, but to what resolution?
> Log file rotation is a solved problem, by time interval or by file size
> or both, compressing and deleting old log files in configurable ways.
> There's no need for each app to reinvent _any_ of it.
Absolutely! Even more so, the whole file writing thing is "solved"
too - by using the system logging facilities (syslog or the Windows
There are major reasons to use the system logging support, such as
centralized logging, configuration control via the standard logging
tools, support/integration with various system monitoring tools, and,
of course, the whole log file rotation, naming, archiving, etc.
Reinventing all of that is both silly and rather costly as the chance
of being able to handle all of features that come "for free" when
doing standard logging mechanisms is nearly impossible. (For example,
can you integrate with WhatsUp Gold? Or how about with SA-Notifier?)
> (Well, on Unix it's a solved problem; I don't know how these things are
> handled on win32, which does have the added difficulty that it's not
> easy to rename a file which a process has open. It might be worth
> keeping this limitation in mind when adding logging to svnserve.)
The Windows thing goes through the "Microsoft Standard" logging
system. Not that it is like any other system (syslog/etc) but it is a
standard for Windows and allows for centralized control and
BTW - Part of the reason for centralized logging is the fact that in
any organization of a reasonable size you end up with many machines
and don't want to have to connect to each to monitor or diagnose a
problem. Plus, there is the security issue of wanting to have the
logs on a separate machine (and secure) such that it is that much
harder for someone to try to cover their tracks. (Done right, it is
nearly impossible.) SOX and other laws now demand more corporate
responsibility and auditability in a number of these areas.
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:Michael.Sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Jun 28 15:57:55 2006