Re: Logging: home-grown mechanism or syslog/event-log?

On Jul 20, 2005, at 7:53 PM, Brian Holmes wrote:

>
> I don't think we are reinventing syslog. Rather, we are simply
> sending out our message to syslog. We want to find a flexible way to
> write out our log messages to syslog and any other viable logging
> system. Files/streams, syslog, daemontools are all just collectors
> for our message, and in the ideal world, we'd want to support them
> all. So, can't we make everyone happy?
>

It's funny. On Monday, kfogel, cmpilato and I came up with a
completely new proposal for logging, but I've not yet mailed to the
list. I'm not entirely sure how it jibes with ghudson's worry about
reinventing wheels and/or being "good citizen" programs.

However, interestingly enough, we've taken previous hints and gone
from a proposal that was entirely svn_repos_t-centric to one which
entirely not so. (!)

Here was our idea:

----
I. Implement a 'logger' class.
    In libsvn_subr, this is just a filtered stream, nothing more.  A  
"logger" object just contains an svn_stream_t to write to, and  
loglevel to control the writing.  We create a bunch of convenience  
constructor APIs, and a single API like
       svn_log_write (logger, loglevel, fmt, ...)
If the loglevel being passed in is <= the logger's internal loglevel,  
we apr_psprintf() the varargs and write the message to the stream.   
Otherwise we do nothing.  This makes the abstract concept of  
"logging" available to any library or program.
II. Encourage use of global logs
   In /etc/subversion/, create a conf file that contains "pointers"  
to an accesslog and errorlog for all svn-related processes to share.   
Admins are free to make the pointers go to private svn logfiles, or  
into syslog, or into a location that some existing log-rolling daemon  
will notice and automatically manage.  It's flexible.
   A server process (or any process that wants to log things) has an  
API to read the 'global' pointers and get back a couple of logger  
objects.  This would be considered a "well behaved" process.  A  
process is also free to ignore this global pointers, and create  
logger objects to write stuff whereever it wishes.  (For example,  
svnserve could still decide to implement per-repository logging if it  
wished, by creating its own logger objects whenever it opens an  
svn_repos_t.)
----
This doesn't seem like very much code to me.  I agree that maybe this  
could be sublimated into APR, but it also seems pretty general and  
simple.  To me, the "big coding task" that's going to create tons of  
churn (and require maintenance) is teaching our servers to *call* the  
logging API in a million places.   The actual logging infrastructure  
described above, even if homegrown, seems pretty tiny to me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org