logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: approach for defining loggers
Date Mon, 31 Aug 2015 22:38:55 GMT
All of this makes me think we need docs for users new to logging...

Gary

On Mon, Aug 31, 2015 at 3:16 PM, Gary Gregory <garydgregory@gmail.com>
wrote:

> On Mon, Aug 31, 2015 at 3:07 PM, Nicholas Duane <nickdu@msn.com> wrote:
>
>> All sounds reasonable to me.  I'm not sure any of the statements you made
>> go against anything I have stated.  Please let me know if you think
>> otherwise.
>>
>> In your authentication module, you log all levels through its logger,
>> right?
>
>
> Yes.
>
>
>> You don't use separate loggers to log different levels do you?
>>
>
> No separate loggers per levels.
>
> Gary
>
>
>>
>> Thanks,
>> Nick
>>
>> > Date: Mon, 31 Aug 2015 15:02:09 -0700
>> > Subject: Re: approach for defining loggers
>> > From: garydgregory@gmail.com
>> > To: log4j-user@logging.apache.org
>> >
>> > I think of levels as "how important is this" and "who needs to know
>> this".
>> > Some of the art of logging is deciding who you audience is. To help your
>> > development team chase down a bug, you want to make sure that the app
>> logs
>> > interesting events at the DEBUG and TRACE level. This is different that
>> > "what it is I am telling this audience", which is where I use loggers.
>> To
>> > tell who comes in and out of the system, I have logging in the
>> > authentication module. To tell what kind of SQL goes to the database, I
>> > have DEBUG logging in my DB interface code.
>> >
>> > I think that once you start chasing down issues and bugs, and writing
>> code
>> > to help you do that, then it might become more obvious, as to what to
>> do.
>> >
>> > Gary
>> >
>> > On Mon, Aug 31, 2015 at 2:51 PM, Nicholas Duane <nickdu@msn.com> wrote:
>> >
>> > > I did look through a bit of documentation on markers:
>> > >
>> > > https://logging.apache.org/log4j/2.0/manual/markers.html
>> > >
>> > >
>> http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
>> > >
>> > > My initial impression is that I don't want to use markers.  What I'd
>> like
>> > > to be able to say is:
>> > >
>> > > "log the way you have been logging in the past.  You don't need to
>> know
>> > > about any special loggers.  Use your own.  Here is a new level for
>> our new
>> > > type of "event".  Use that to log this new event."
>> > >
>> > > I guess I'm not understanding your vernacular in terms of levels.  In
>> my
>> > > mind the different levels also define different "types" of events.
>> For
>> > > instance, DEBUG and less specific I would see as tracing type events
>> which
>> > > are non-functional in nature.  They are purely for understanding the
>> call
>> > > flow, or for performance gathering, or detailed diagnosis.  Those
>> could be
>> > > turned off totally without having much impact on system management.
>> The
>> > > same can't be said for FATAL to INFO.  These levels should always be
>> on so
>> > > that you can properly manage the system.
>> > >
>> > > Thanks,
>> > > Nick
>> > >
>> > > > Date: Mon, 31 Aug 2015 08:37:25 -0700
>> > > > Subject: Re: approach for defining loggers
>> > > > From: garydgregory@gmail.com
>> > > > To: log4j-user@logging.apache.org
>> > > >
>> > > > Hi Nick,
>> > > >
>> > > > Creating a single new level is seldom the right solution IMO. It's
>> not
>> > > like
>> > > > you are missing a level of granularity (we have custom level
>> examples
>> > > that
>> > > > demonstrate that, like a VERBOSE level that sits between INFO and
>> DEBUG).
>> > > > It sounds like you need to use _hierarchical_ loggers and/or
>> markers.
>> > > >
>> > > > The fact that the level is called BUSINESS is also a hint that a
>> level is
>> > > > not quite right because it does not fit in the Level vernacular
>> (INFO,
>> > > > WARN, and so on).
>> > > >
>> > > > If you needed a different set of levels, that would be another story
>> > > (like
>> > > > the DEFCON levels example).
>> > > >
>> > > > Gary
>> > > >
>> > > > On Mon, Aug 31, 2015 at 8:10 AM, Nicholas Duane <nickdu@msn.com>
>> wrote:
>> > > >
>> > > > > Thanks for the feedback.  I will look into Markers and MDC.
>> > > > >
>> > > > > With respect to using a separate logger, it would seem I would
>> lose the
>> > > > > information about what application code, eg. the class logger,
is
>> > > sourcing
>> > > > > the event.  We would like to have this information.  On top of
>> that, it
>> > > > > seems odd, maybe to me only, that for this new level we have
our
>> own
>> > > > > logger.  It seemed reasonable to me that this new event we want
to
>> > > capture
>> > > > > is just a new level.  Just like a DEBUG event is different from
>> an INFO
>> > > > > event.  If I define a BUSINESS level why would that not follow
>> the same
>> > > > > design as the current levels?  You wouldn't suggest having
>> different
>> > > > > loggers for TRACE DEBUG INFO WARN ERROR FATAL, would you?  I
>> think one
>> > > of
>> > > > > the reasons someone on our side is suggesting I have separate
>> loggers
>> > > is
>> > > > > that they think the overhead of filtering at the appender is
>> going to
>> > > have
>> > > > > a noticeable impact.  Our plan, at least the one I have now in
my
>> > > head, is
>> > > > > that we'll have some number of appenders in the root.  We'll
then
>> > > filter x
>> > > > > < INFO events to a tracing appender, INFO <= x <= FATAL
to a
>> logging
>> > > > > appender, and our custom level will go to another appender.
>> Thoughts?
>> > > > >
>> > > > > Thanks,
>> > > > > Nick
>> > > > >
>> > > > > > Subject: Re: approach for defining loggers
>> > > > > > From: ralph.goers@dslextreme.com
>> > > > > > Date: Sat, 29 Aug 2015 20:59:36 -0700
>> > > > > > To: log4j-user@logging.apache.org
>> > > > > >
>> > > > > >
>> > > > > > > On Aug 29, 2015, at 7:44 PM, Nicholas Duane <nickdu@msn.com>
>> > > wrote:
>> > > > > > >
>> > > > > > > I'm curious if there is a prescribed approach to defining
>> loggers.
>> > > > > Let me state what my assumption is.  I assume that normally if
>> some
>> > > piece
>> > > > > of code wants to log events/messages that it should create a
>> logger for
>> > > > > itself.  I guess a reasonable name to use is the class name
>> itself.  In
>> > > > > terms of logger configuration I would expect that no loggers
are
>> > > specified
>> > > > > in the log4j configuration UNLESS is needs settings other than
the
>> > > > > default.  The root logger would specify the default settings,
eg.
>> > > level and
>> > > > > appenders.  If some piece of code tied to a logger needs to enable
>> > > tracing
>> > > > > in order to debug an issue then you would add that logger to
the
>> > > > > configuration and set the level less specific for that logger.
 Is
>> > > this a
>> > > > > typical and reasonable approach?
>> > > > > >
>> > > > > > What you describe here is the common convention. It is a
>> reasonable
>> > > > > approach.
>> > > > > >
>> > > > > > >
>> > > > > > > I asked because we have the need for a new type of
event.  To
>> have
>> > > > > this event flow to where we want it to flow the plan is to have
a
>> > > custom
>> > > > > level and have all events at that level captured by a specific
>> > > appender.
>> > > > > My assumption was that for existing applications we'd just need
>> to add
>> > > our
>> > > > > appender to the root and add our custom level.  The app would
>> need to
>> > > be
>> > > > > modified to log our new event at the custom level.  However,
>> someone
>> > > > > suggested that we could also create a separate logger for this
>> event.
>> > > My
>> > > > > thinking is that while we don't ever want to turn off logging
of
>> this
>> > > > > event, loggers represent "event sources", e.g the code raising
the
>> > > events
>> > > > > and thus having multiple different pieces of code use the same
>> logger
>> > > > > wouldn't allow you to turn on/off logging from those different
>> > > sections of
>> > > > > code independently.  I think the current configuration includes
>> all the
>> > > > > loggers.  Normally I would expect there to be many, on the order
>> of
>> > > 10's or
>> > > > > 100's, loggers within an application.  However, in the case I
was
>> given
>> > > > > there were only a handful because I think this handful is
>> shared.  So
>> > > as I
>> > > > > mentioned, this doesn't sound like an ideal design as you have
>> less
>> > > > > granularity on what you can turn on/off.
>> > > > > >
>> > > > > > You have a few options. Using a CustomLevel would not be
the
>> option I
>> > > > > would choose.  Creating a custom Logger will certainly work and
>> makes
>> > > > > routing the message to the appropriate appender rather easy.
>> Another
>> > > > > approach is to use Markers.  Markers are somewhat hierarchical
so
>> you
>> > > can
>> > > > > use them for a variety of purposes.  If you look at how Log4j
>> handles
>> > > event
>> > > > > logging it actually does both - it specifies EventLogger as the
>> name
>> > > of the
>> > > > > logger to use and it uses Markers to identify the kind of event.
>> > > > > >
>> > > > > > A third option is to use the MDC or Logger properties. If
you
>> do that
>> > > > > then you can have information included in the actual logging
event
>> > > that can
>> > > > > affect how it is routed. I also built a system that uses the
>> RFC5424
>> > > format
>> > > > > so that the event could have lots of key/value pairs to identify
>> the
>> > > events.
>> > > > > >
>> > > > > > Unfortunately, without knowing more details I don’t know
that I
>> can
>> > > give
>> > > > > you a better idea on how I would implement it.
>> > > > > >
>> > > > > > Ralph
>> > > > > >
>> > > > > >
>> ---------------------------------------------------------------------
>> > > > > > To unsubscribe, e-mail:
>> log4j-user-unsubscribe@logging.apache.org
>> > > > > > For additional commands, e-mail:
>> log4j-user-help@logging.apache.org
>> > > > > >
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> > > > Java Persistence with Hibernate, Second Edition
>> > > > <http://www.manning.com/bauer3/>
>> > > > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> > > > Spring Batch in Action <http://www.manning.com/templier/>
>> > > > Blog: http://garygregory.wordpress.com
>> > > > Home: http://garygregory.com/
>> > > > Tweet! http://twitter.com/GaryGregory
>> > >
>> > >
>> >
>> >
>> >
>> > --
>> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> > Java Persistence with Hibernate, Second Edition
>> > <http://www.manning.com/bauer3/>
>> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> > Spring Batch in Action <http://www.manning.com/templier/>
>> > Blog: http://garygregory.wordpress.com
>> > Home: http://garygregory.com/
>> > Tweet! http://twitter.com/GaryGregory
>>
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message