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 Fri, 11 Sep 2015 04:21:09 GMT
This thread inspired me to explain logging concepts:

https://garygregory.wordpress.com/2015/09/10/the-art-of-test-driven-development-understanding-logging/

I hope it helps!

Gary

On Wed, Sep 9, 2015 at 12:47 AM, Mikael Ståldal <mikael.staldal@magine.com>
wrote:

> Then perhaps you should create your own facade for doing business event
> logging, which could then forward them to Log4j in an appropriate way.
>
> On Wed, Sep 9, 2015 at 4:49 AM, Nicholas Duane <nickdu@msn.com> wrote:
>
> > I was just about to reply to your previous email about using a single
> > "business" logger, or some hierarchy of business loggers, to log business
> > events and say that we might go that route.  However, now that you
> brought
> > up the post from Ralph, which I just replied to, I'm thinking a logger
> > won't work either for the same reason I listed in my reply to Ralph's
> post.
> >
> > You could do:
> >
> > logger.info("Hello");
> > logger.fatal("Hello");
> > logger.error("Hello");
> > ...
> >
> > It's confusing as there are n ways to log a business event that way and
> > they will all do the same thing.  Which one should a developer choose.
> > Should I say pick any one, it doesn't matter?
> >
> > Thanks,
> > Nick
> >
> > > Date: Tue, 8 Sep 2015 19:28:21 -0700
> > > Subject: Re: approach for defining loggers
> > > From: garydgregory@gmail.com
> > > To: log4j-user@logging.apache.org
> > >
> > > Or
> > > Logger logger = LogManager.getLogger("Business");
> > > ...
> > > logger.info("Hello");
> > >
> > > Gary
> > >
> > > On Tue, Sep 8, 2015 at 7:24 PM, Ralph Goers <
> ralph.goers@dslextreme.com>
> > > wrote:
> > >
> > > > Can you please clarify, “If we had some way to know an event is a
> > business
> > > > event we wouldn’t need level”?  I do not understand how you can code
> > > > logger.log(BUSINESS, msg)  but you cannot code logger.info(BUSINESS,
> > msg).
> > > >
> > > > Ralph
> > > >
> > > > > On Sep 8, 2015, at 6:09 PM, Nicholas Duane <nickdu@msn.com>
wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > I looked over that stackoverflow post and I'm still not seeing a
> good
> > > > match as a way for us to log our business events.
> > > > >
> > > > > A business event I guess is an event which extends whatever schema
> we
> > > > come up with for a business event.  While an instance of this schema
> > could
> > > > be logged at any level, that really doesn't make sense in our
> scenario,
> > > > regardless of whether some marker was supplied.  If we had some way
> to
> > know
> > > > an event is a business event we wouldn't need level.  We could of
> > course
> > > > add some property to our schema which indicates the 'category' of the
> > > > event, 'business' being one such category.  Instead we were thinking
> we
> > > > could just use level to indicate that an event is a business event.
> > > > >
> > > > > As I mentioned, we're looking to capture 'trace' level events to
> one
> > > > store, 'info' - 'fatal' level events to another store, and 'business'
> > > > events to yet another store.  For 'trace' and 'info' - 'fatal' it
> seems
> > > > reasonable to filter on level within the appender to get those events
> > to
> > > > the appropriate location.  It seemed reasonable to do something
> > similar for
> > > > 'business'.
> > > > >
> > > > > I also looked into the EventLogger but not sure that's appropriate.
> > For
> > > > one we lose the granularity to control a specific piece of code from
> > > > generating business events.  This is most likely a non-issue as I
> have
> > > > mentioned that we don't want to turn business logging off.  The other
> > is
> > > > that we lose the name of the logger as it would be the same for
> > everyone.
> > > > Not sure this is that big a deal either as I guess you might be able
> to
> > > > capture component name, though I would rather distinguish using
> logger
> > name.
> > > > >
> > > > > Thanks,
> > > > > Nick
> > > > >
> > > > >> From: ralph.goers@dslextreme.com
> > > > >> Subject: Re: approach for defining loggers
> > > > >> Date: Mon, 7 Sep 2015 20:39:11 -0700
> > > > >> To: log4j-user@logging.apache.org
> > > > >>
> > > > >> I still don’t understand why you don’t want to use Markers.
They
> > were
> > > > designed exactly for the use case you are describing.
> > > > >>
> > > > >> You might set retention policies for debug vs info, error and
> fatal,
> > > > but a BUSINESS marker could cross-cut them all.  That is exactly why
> > it is
> > > > NOT a level. IOW, it gives you a second dimension for filtering. Ceki
> > > > invented Markers when he created SLF4J. For his point of view see
> > > >
> >
> http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
> > > > <
> > > >
> >
> http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
> > > > >.
> > > > >>
> > > > >> Ralph
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>> On Sep 7, 2015, at 5:54 PM, Nicholas Duane <nickdu@msn.com>
> wrote:
> > > > >>>
> > > > >>> 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.
> > > > >>>
> > > > >>> Thanks,
> > > > >>> Nick
> > > > >>>
> > > > >>>> 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 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
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > ---------------------------------------------------------------------
> > > > >>>> 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
> > > >
> > > >
> > >
> > >
> > > --
> > > 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
> >
> >
>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@magine.com
> Regeringsgatan 25  | 111 53 Stockholm, Sweden  |   www.magine.com
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>



-- 
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