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(a)redhat.com>
To: rhq-devel(a)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(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel