$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [logging] Interest check on logging library.
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-12-29 11:26:03
Jason Wagner wrote:
> One of the projects I deal with can generate several hundred MB of logs
> over the course of a day if we have logging cranked up. We log both as
> an light audit trail and a debugging tool. Dealing with that much
> information can become rather difficult. There are a few things that
> come to mind that I would change in it:
>
> 1) When reading the code, logging should scan like a comments-- they
> should be readable and informative but ignorable. A lot of logic,
> conditionals, or even excessive formatting distracts from figuring out
> what a function actually does. Severity (debug, warning, error, etc) is
> only one dimension, though the most common. If I add new dimensions,
> how much does that affect complexity of the conditionals? What are the
> chances of mistyping one of the conditionals and not getting a logging
> message?
>
> 2) The logging output needs to be well formatted, readable, and broken
> up into manageable pieces. Imagine getting a packet or request in, then
> having to dump it. Does it show up as one or two records? Does it end
> up on a 500 character wide line? How much overhead should one add to
> the site of the logging call to format this? If I split my files into
> an log file that contains everything and an audit file that only
> contains some, should the formatting be the same? What if I want to
> merge them at a later time, do I need to edit everything and recompile?
> What if I want to change output and direction at runtime? Do I think of
> all of that in the function, or do I configure the logging and just let
> it fly?
>
> The former implies that there should be an abstraction around the logic
> of whether a record gets logged. The latter implies an abstraction
> around formatting and how to determine the destination of the record.
> That and a few extra bows is the extent of what I'm trying to do.
Sorry, couldn't resist. I think, my library fits these requirements
quite well. Why would you start your own implementation from scratch? Is
there something that doesn't suit you in my implementation?