Logging verbosity

Jiri Kremser jkremser at redhat.com
Fri Dec 20 01:21:01 UTC 2013


Hi,
 I am reacting to 
"
One more thing, I can't remember whether it's in use anymore, it may 
have been part of the selenium work, but I had a utility that was 
useful, it took a stack trace and squashed it to include only org.rhq.* 
entries.  This presented tiny stacks of typically the most useful info.
"

I've done something similar (not the squashing, but the highlighting of )







----- Original Message -----
> From: "Jay Shaughnessy" <jshaughn at redhat.com>
> To: rhq-devel at lists.fedorahosted.org
> Sent: Wednesday, December 18, 2013 4:12:09 PM
> Subject: Re: Logging verbosity
> 
> 
> I don't think there is a rule to be applied.  It's important to provide
> context when logging, which is a problem we often have in our log
> messages (beware logging with no '+' signs in the supplied message
> String...).  But log spamming is also a problem.  It's critical not to
> flood the log with a repetitive message.  I'm sensitive to the Agent
> log.  When you see stack traces in here it makes you question the
> validity of your collected data.  Moreover, I'm even more sensitive to
> verbose logging for issues in plugin code, which we can't control very
> well.  And since availability executes very frequently, logging a stack
> trace due to a plugin code problem, on every avail check, could get
> problematically verbose.
> 
> I think it's a judgement call.  I'm assuming this was my change since I
> was recently doing some more avail work, I don't remember exactly the
> motivation, but perhaps after examining the previous logging I decided
> this was better.  Not sure.  Anyway, if you're passionate about this
> one, feel free to change it back.  But I wouldn't apply a general rule
> as to whether to show a stack or not. For what it's worth, DEBUG is also
> useless when too verbose. Although, with some logging config work to
> suppress certain things, it can be made better.
> 
> One more thing, I can't remember whether it's in use anymore, it may
> have been part of the selenium work, but I had a utility that was
> useful, it took a stack trace and squashed it to include only org.rhq.*
> entries.  This presented tiny stacks of typically the most useful info.
> 
> On 12/17/2013 1:00 PM, Lukas Krejci wrote:
> > Recently, I noticed this as part of one commit:
> >
> >                       LOG.warn("Availability collection failed with
> >                       exception on " + resource
> > -                        + ", availability will be reported as " +
> > DOWN.name(), t);
> > +                        + ", availability will be reported as " +
> > DOWN.name() + ", reason=" + t.getMessage());
> >
> > I am personally very much FOR having stacktraces in the log messages,
> > especially in erroneous conditions like this one (i.e. IMHO almost any log
> > message on WARN and ERROR levels SHOULD have a stacktrace attached). The
> > reason is that including just the error message in the log loses
> > information that would be very valuable during debugging potential bugs
> > (even more so in a complex code like avail collection).
> >
> > Is there a policy/consensus of sorts for inclusion/exclusion of full
> > stacktraces in the log messages?
> >
> > Cheers,
> >
> > Lukas
> > _______________________________________________
> > 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