RE: [boost] Logging Library -- Formal Review Request

From: Bennett, Patrick (Patrick.Bennett_at_[hidden])
Date: 2005-04-26 13:14:37

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of Jody Hagins
> Sent: Tuesday, April 26, 2005 11:40 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] Logging Library -- Formal Review Request
> 
> On Tue, 26 Apr 2005 12:16:03 -0400
> Caleb Epstein <caleb.epstein_at_[hidden]> wrote:
> 
> 
> > I think John's approach to having multiple log "levels" is to just
use
> > a separate log for each one (e.g. you might have logs called trace,
> > debug, warning, info, and fatal).  Logs are either enabled or
> > disabled; there is no "level" or above-some-threshold-type checking
as
> > with some other common implementations.
> 
> 
> Unfortunately, you lose relativity in logs, which is very important in
> diagnosing failures.  Suppose a problem occurs that gets logged to the
> "fatal" log.  Really, to find out all surrounding context, you need to
> merge all logs.  Unless there is a common sequence number or something
> like that, you have no way of really knowing what sequence of events
led
> to the problem since they are scattered about in a number of logs.
You
> can make good guesses, but in large that handle multiple requests at
the
> same time, it becomes very difficult.
> 
> I'd prefer a common log, which records levels.
> 
> I also think the concept of multiple log variables is important in
large
> systems, where different subsystems may have different log levels
(e.g,
> turn on all logging for new subsystems, and only critical logging for
> other subsystems).

[Bennett, Patrick] Agreed.  With the current system I use, there are
have multiple logging 'topics,' each of which can be assigned real-time
a 'current' tracing/verbosity level.  Each logging macro is defined as
being a particular verbosity level as well - so things like
status/notes/warning/error/etc. break down into general verbosity level
ranges.  A specific message type is associated with the message as well,
although it typically matches the verbosity definition.

Specific topics can then be associated with one or more logging 'sinks.'
Logging a message for any given topic will only happen if its currently
set level is >= the level the message is defined to log at.  The message
then gets sent to all associated sinks (for output across the network,
to disk, to the console, etc.).  

The topics are associated with the named 'subsystem' (typically a
friendly version of the process name) [the subsystem/topic name is what
defines a unique topic] and can be modified from other management
processes by adjusting levels per subsystem or by topics used by it.

In my mind at least, it would be nice to see the boost logging library
adopt some of these concepts. 

Patrick Bennett