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