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, 08 Sep 2015 00:54:33 GMT
If I'm attempting to control all the logging from the configuration and I don't know the complete
set of loggers in my application as there could be 100's or 1000's, wouldn't it be hard to
separate events based on loggers?  It would seem much easier to separate events based on level.
 In addition, level might be a more reasonable approach for separating.  For example, if I
want to send all events to some big-data backend I might want to separate out traces and debug
from info to fatal as traces and debug are most likely less important from a systems management
aspect.  My retention period for traces and debug might be just a couple days.  The retention
period for info to fatal could be 30 days.  Business level might be 2 years.  Any system management
notifications would probably be driven off of info to fatal events and not trace and debug
events, which is another reason you might want to separate by level.  
> Subject: Re: approach for defining loggers
> From: ralph.goers@dslextreme.com
> Date: Mon, 31 Aug 2015 08:50:58 -0700
> To: log4j-user@logging.apache.org
> A logging “Level” is a level of importance. That is why there is a hierarchy. If
you want informational messages then you also would want warnings and errors.
> “BUSINESS” does not convey the same meaning.  Rather, it is some sort of category,
which is what Markers are for.
> Using the class name as the logger name is a convention. If you really want the class
name, method name or line number then you should be specifying that you want those from the
logging event, rather than the logger name.  Unless location information is disabled you always
have access to that information.
> In short, different loggers are used primarily as a way of grouping sets of messages
- for example all org.hibernate events can be routed to a specific appender or turned off
en masse. Levels are used to filter out noise across a set of logging events. Markers are
used to categorize logging events by arbitrary attributes.
> Ralph
> > On 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
> >> 
> >> 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
> >> 
> > 		 	   		  
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message