[openstack-dev] [log] LOG.exception should contain an exception message or not?

Doug Hellmann doug at doughellmann.com
Tue Jan 5 14:42:13 UTC 2016


Excerpts from Sean Dague's message of 2016-01-05 08:31:34 -0500:
> On 01/05/2016 08:08 AM, Akihiro Motoki wrote:
> > Hi,
> > 
> > # cross-posting to -dev and -operators ML
> > 
> > In the current most OpenStack implementation,
> > when we use LOG.exception, we don't pass an exception message to LOG.exception:
> > 
> >   LOG.exception(_LE("Error while processing VIF ports"))
> > 
> > IIUC it is because the exception message will be logged at the end of
> > a corresponding stacktrace.
> > 
> > We will get a line like (Full log: http://paste.openstack.org/show/483018/):
> > 
> >   ERROR ... Error while processing VIF ports
> > 
> > [Problem]
> > 
> > Many logging tools are still line-oriented (though logstash or fluentd
> > can handle multiple lines).
> > An ERROR line only contains a summary message without the actual failure reason.
> > This makes difficult for line-oriented logging tools to classify error logs.
> > 
> > [Proposal]
> > 
> > My proposal is to pass an exception message to LOG.exception like:
> > 
> >   except <some exception> as exc:
> >      LOG.exception(_LE("Error while processing VIF ports: %s"), exc)
> > 
> > This alllows line-oriented logging tools to classify error logs more easily.
> 
> What tools are you talking about here?
> 
> Realistically this is a trade off. Stack traces should only be happening
> under exceptional circumstances, which means a user is going to be
> engaged. The user is going to have a much easier time reading an
> exception in a log if it's not got all the whitespace compressed out of it.
> 
> If it's possible to recover, the code that is generating the exception
> shouldn't be logging it, but instead should do some kind of structured
> recovery.
> 
>     -Sean
> 

Right, LOG.error() with a summary of an error is better. Stack traces
should really only be logged as a last resort.

Doug



More information about the OpenStack-dev mailing list