logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Duane <nic...@msn.com>
Subject RE: approach for defining loggers
Date Tue, 01 Sep 2015 22:26:28 GMT
I was re-reading this and thought I should respond.  You mentioned that levels are used to
indicate the importance of what you logged.  The logger helps you with "what is it that I'm
trying to tell" the audience, if I have that correct.  Which I kind of agree.  The logger,
in my mind, indicates the "area" of code which is sourcing the events.  In your example you
have an authentication module which has its own logger.  All events (hopefully using the terms
events is ok) logged from that logger has to do with authentication.  The authentication module
uses its logger to log events at different levels.  So in my scenario, the authentication
module might want to log a "Business" event.  In reality this probably would not happen as
the business events would most likely be sourced from LOB application code.  However, each
component of LOB application code might have its own logger and if it needs to log a business
event it should do so from its logger.
 
I did look at markers and it would seem if I used them for these business events I would still
be logging the business events at some level and would include a marker.  This seems odd to
me as the level would seem pointless and thus picking one would be arbitrary.
 
Someone had mentioned using the EventLogger.  I still have to look into that, but that sounds
like a single logger which I initially thought was not required and instead the advice would
be to log via whatever logger you're using for your other events.  However, maybe the EventLogger
will work.
 
Thanks,
Nick

 
> Date: Mon, 31 Aug 2015 15:16:49 -0700
> Subject: Re: approach for defining loggers
> From: garydgregory@gmail.com
> To: log4j-user@logging.apache.org
> 
> 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
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message