-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jody Hagins Sent: Tuesday, April 26, 2005 11:40 AM To: boost@lists.boost.org Subject: Re: [boost] Logging Library -- Formal Review Request

On Tue, 26 Apr 2005 12:16:03 -0400 Caleb Epstein <caleb.epstein@gmail.com> 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