Hello!
On 11/19/2015 3:48 AM, kirk.pepperd...@gmail.com wrote:
Hi David,
You enable the logging with "-Xlog:vmoperation=debug". If you leave of
the "=<level>" portion, it is by default parsed as "=info". We don't
believe this vmoperation logging needs to come out by default in the
case where someone asks for "-Xlog:all", so we put it one level below.
<sigh> So does -Xlog:all signify all tags at info level or ???
I think this is real conceptual problem with the UL framework. I should be able to define
the info/trace/debug levels for a given tag, without having to think about how they
interact with a "log all" request.
This has been one of my concerns about UL since the initial JEP and why I was
speaking towards UL being tag based instead of level based. Now, IMO, UL is
backwards in that it is geared towards levels but that is confused with tags.
Being geared towards tags with levels would have created less of a conceptual
problem. And, it is more inline with how other messaging systems work (given
that logging is a specialization of messaging).
Thanks for voicing your concern. The justification for this tag being
product is that it could be useful to helping diagnose user problems, it
does not slow performance when off, and it minimally increases the size
of the code. If any of these prove to be false in aggregated logging
options, we can move it to develop level during code freeze.
You could make that argument for every piece of logging and end up with a very
simple flat logging system. :) It is all very subjective of course.
Agreed, slippery slope but in this case I’m happy that we will now have access
to this type of information in production environments. What we currently have
are indications of a problem without any real means of seeing what the problem
is.
My rule of thumb for using log levels is
debug - detailed information that a developer needs. It would have limited
value to diagnosing problems in production systems
warning - defensive action needed to be taken, or an action couldn’t be taken
to avert something bad from happening
info - an event occurred (such as jvm operation, GC, safe-point, CHA event…..)
I would not want “all" to include “debug”. So, not exactly the hierarchical
escalation that is being forced on us.
Just want to make sure we're all on the same page. Your rules of thumb
are pretty accurate. The levels are as follows (directly from
logLevel.hpp) and aggregate the levels below them:
// develop - A non-product level that is finer than trace.
// Should be used for really expensive and/or
// extensive logging, or logging that shouldn't
// or can't be included in a product build.
//
// trace - Finest level of logging in product builds.
// Use for extensive/noisy logging that can
// give slow-down when enabled.
//
// debug - A finer level of logging. Use for semi-noisy
// logging that is does not fit the info level.
//
// info - General level of logging. Use for significant
// events and/or informative summaries.
//
// warning - Important messages that are not strictly errors.
//
// error - Critical messages caused by errors.
"Info" is default, which would include only the levels "warning",
"error", and "info".
I used "-Xlog:all" as an example; it's not inherently central to the
purpose of levels. It means print logging for all tags. But by not
specifying a level, you get "info", which does not have "debug."
Rachel
Kind regards,
Kirk
