Logging verbosity

Lukas Krejci lkrejci at redhat.com
Tue Dec 17 23:17:31 UTC 2013


I'm not sure I can agree with that..

Customer: We have this issue, our server doesn't work.
Support: What does the log say?
Customer: [ERROR] - Failed to collect important stuff because of: null (this 
is just to exacerbate the change in logging I started this thread with).
Support: Oh, could you please go back to your server and replicate the issue 
with debug logging on? We need to see the stacktraces.
Customer: You mean reconfiguring a production server? Why didn't include 
enough info in the message so that you can diagnose the error?

Or a slightly different conversation:
... start off the same as above ...
Support: We can't diagnose the issue unless we send you a diagnostic patch.
Customer: What kind of muppets are you, seriously?

What you say is correct, but not sufficient IMHO - the information the log 
message provides should be digestable by non-developers. But at the same time,  
it should also provide the developer with enough info to diagnose the 
underlying issue. And the more severe the log message is, the more it applies. 

This of course doesn't mean that the stacktrace has to be provided - if there 
is only one way an exception could be raised, we don't have to necessarily log 
it (and the change that started this thread seems to be in that category). 
Unfortunately our code contains quite a lot of "catch (Exception e)" or even 
"catch  (Throwable t)". These catch-all blocks don't lend themselves to that 
approach too well. 

On Tuesday, December 17, 2013 13:47:45 Larry O'Leary wrote:
> On Tue, 2013-12-17 at 20:38 +0100, Heiko W.Rupp wrote:
> > Am 17.12.2013 um 19:00 schrieb Lukas Krejci <lkrejci at redhat.com>:
> > > I am personally very much FOR having stacktraces in the log messages,
> > > especially in erroneous conditions like this one (i.e. IMHO almost> 
> > If our stacktraces would only contain relevant information I would agree.
> > 
> > Spitting out the same 30 lines over and over again does not add any value.
> > A lot of what is written is stuff inside java.* . Also for above case, the
> > trace is always the same, and leads to the place you pointed out. That
> > trace does not tell anything about the cause, which is what we would want
> > in reality.
> > 
> > We may log the traces at a different level that is off by default though.
> 
> I would only expect to see stack traces at DEBUG level. At any log level
> below that, I would expect the log message to provide me with the most
> relevant information in a non-Java or non-developer context.


More information about the rhq-devel mailing list