Open Stack

Excerpts from Alexis Lee's message of 2016-05-26 11:58:46 +0100:
> Doug Hellmann said on Wed, May 25, 2016 at 11:56:55AM -0400:
> > But that leaves it up to the application or library author to have to
> > make that call for every log message, which makes logging more
> > complicated.
> 
> Almost all messages generated while processing a request should only go
> to the request logger. If a message is obviously important outside the
> context of that single request, it can also/instead be logged to the
> normal logger, but this should very much be the exception to the rule.
> 
> > The point of the spooling logger is to dump everything about a request
> > when the request fails, right? And we want the "normal" behavior the
> > rest of the time? It seems like we should look at a way to make that
> > happen without a lot of impact on application logic.
> > 
> > It's OK to have the same message go to both loggers, right? Could we
> > have a wrapper class that takes a normal logger and a spooling logger
> > and sends its messages to both?
> 
> No, definitely not. Log records associated with successful requests
> should not be emitted at all. This will make the practice of running at
> DEBUG more bearable. IE the goal is to reduce logging volume, not double
> it!
> 
> > Even better would be to find a way to configure the logger hierarchy
> > so that is completely transparent, so that messages going to the
> > SpoolLogger are propagated to the normal logger based on their log
> > level.
> 
> The logger a message should go to is orthogonal to its level. If a
> requested resource, which should exist, does not - this might be logged
> at ERROR, a very high level. It doesn't need to go to the normal log
> though because it's strictly to do with that request. So if we duplicate
> all high level logs to the normal logger, we'll see unnecessary records
> in the normal log.
> 
> If someone really wanted these duplicates, they could add their normal
> handler to the 'spool' logger with a high loglevel.
> 
> 
> Alexis (lxsli)

I'm not sure silencing all messages for successful requests is a good
idea. That was not my understanding of the intent of this work, for
sure. I thought the idea was to run the spool logger at debug, but
maintain the other normal logging at info level so that monitoring
systems could still do things like track request rates and whatever else
one might want to do with logs aside from debugging failures.

Doug