Logging verbosity

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


On Tuesday, December 17, 2013 12:09:34 mike thompson wrote:
> On Dec 17, 2013, at 12:05 PM, John Sanda <jsanda at redhat.com> wrote:
> > On Dec 17, 2013, at 2:47 PM, Larry O'Leary <loleary at redhat.com> 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.
> > 
> > I agree that in general stack traces should appear at DEBUG. Now I need to
> > go check and see how often I violate that :)
> When things are going horribly wrong, stack traces can add to the log files
> filling up and exacerbating the situation further such that your system is
> frozen and you can't even access the log files -- I've been there ;)

"The log is so void of information one cannot diagnose what might have gone 
wrong and needs to send a diagnostic patch to the customer hoping the added 
logging will catch the issue. Force the customer to try and replicate the 
issue with the patch applied. Rince and repeat until the issue is solved."

I've been there ;)

As with everything, I think it's about finding a good compromise. In this case 
I was a bit surprised to see information removed from a warning message, which 
we generally use in situations that might be bugs. I'm not saying it was wrong 
to remove the stacktrace in this particular case though. I just used it as an 
example to start off the discussion.

> >> _______________________________________________
> >> rhq-devel mailing list
> >> rhq-devel at lists.fedorahosted.org
> >> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > 
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list