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: status appender?
Date Tue, 15 Dec 2015 00:49:38 GMT
Good question.  We currently have an instrumentation framework, in .NET, which we use to log
events and capture centrally.  This was developed back in 2001 and has served us well.  When
we discussed capturing these new events we decided that it would be best to use a leading
logging framework if possible instead of develop our own.  While these business events are
the ones in scope now, eventually we plan to capture all the application events.  The pieces
I mentioned below, the log4j2 appenders and the domain socket daemon, is just the conduit
we've developed to simplify application getting their events to our API.  Our API will consist
of several "protocol" endpoints, like HTTP, FTP, MQ, etc.  These endpoints will accept events
and then funnel them to an HDFS data lake.

Thanks,
Nick

> From: remko.popma@gmail.com
> Subject: Re: status appender?
> Date: Tue, 15 Dec 2015 06:20:24 +0900
> To: log4j-user@logging.apache.org
> 
> Nick,
> 
> Are you sure you want to use a logging framework for this? When I hear terms like "business
event" and "domain socket appender" that makes me think you may want to look at some message
oriented middleware solution, like JMS or the like. 
> 
> Remko 
> 
> Sent from my iPhone
> 
> > On 2015/12/15, at 3:27, Nicholas Duane <nickdu@msn.com> wrote:
> > 
> > I'll give a brief description on the setup so that hopefully you have a better picture.
> > 
> > We want to capture a specific type of event, let's say a business event, from all
the applications on the box and get them to a central location.  We're also looking ahead
to a possible PaaS environment and thinking that writing to log files might not be an option.
 Our solution is that all the applications on the box will use our domain socket appender
to write these business events into.  In addition, there will be a daemon on this box listening
on the domain socket.  It will buffer, compress and send the events to a central location.
 Even if we don't want to take into consideration the PaaS environment and thus can consider
writing to local files (as I guess that's the most common logging solution and has its benefits),
there might be issues there.  For instance, let's say we have a process which picks up log
files and sends them centrally.  What happens when new applications are installed on the box?
 We would probably have to update the configuration of this "log file consolidator" to watch
new folder locations.  That might be a bit of a maintenance nightmare.
> > 
> > If the domain socket appender runs into issues, like it can't open the socket, we
need for someone to look into it.  I guess the thinking is that if we get these ERROR/INFO
events to a central location we can have some monitoring there to address these issues.
> > 
> > We also, currently, are failing over the event sent to the domain socket appender
to the domain socket appender's logger, which I guess is what you're referring to by "Routing
events being processed by an Appender through a Logger is a bad idea.".  While that is happening
now, that's not the main question I have here.  It's about how to send INFO - ERROR to one
location, or possibly two, and have DEBUG only go to the status logger.
> > 
> > There is push back on "failing over" the events from the domain socket appender
so that code might get pulled out.
> > 
> > Thanks,
> > Nick
> > 
> >> Subject: Re: status appender?
> >> From: ralph.goers@dslextreme.com
> >> Date: Mon, 14 Dec 2015 10:56:11 -0700
> >> To: log4j-user@logging.apache.org
> >> 
> >> I don’t think I understand - “we’re writing to our own logger within our
DomainSocketAppender”.  The status logger in your appender should only be logging errors
or other events that occur within that Appender, which normally would be nothing. Routing
events being processed by an Appender through a Logger is a bad idea.
> >> 
> >> Ralph
> >> 
> >> 
> >> 
> >>> On Dec 14, 2015, at 10:17 AM, Nicholas Duane <nickdu@msn.com> wrote:
> >>> 
> >>> Thanks.  Yes, that's the one option I was thinking of.  Adding a console
or file appender to our logger.  However, the actual class in question is our DomainSocketAppender.
 This is somewhat related to a previous question I asked about capturing events from our appenders
centrally.  I guess in general, the advice is to log to the status logger in your log4j2 classes.
 We want to capture INFO - ERROR messages centrally so we're writing to our own logger within
our DomainSocketAppender.  It would be nice to have all other events, DEBUG and less specific
(or maybe just all events), go to the status logger and let the application team decide what
they want to do with status logger events.
> >>> 
> >>> I was just thinking that one other solution would be to log all events within
our DomainSocketsAppender to both its private logger and the status logger, thus somewhat
removing the "routing" within the code.  Our filter on the http appender already filters out
anything less specific than INFO.
> >>> 
> >>> Thanks,
> >>> Nick
> >>> 
> >>>> Subject: Re: status appender?
> >>>> From: ralph.goers@dslextreme.com
> >>>> Date: Mon, 14 Dec 2015 09:32:51 -0700
> >>>> To: log4j-user@logging.apache.org
> >>>> 
> >>>> First, what you are wanting to do is, in fact, pretty normal.  However,
by default the StatusLogger that Log4j uses for its components doesn’t use an Appender.
Although the API is the same the internals of the StatusLogger are actually quite different
than the “normal” Log4j implementation.  That said, the StatusLogger normally just writes
to the console.  I actually doubt that that is where you want your debug events to go.  Most
people prefer them to go to a rolling file.
> >>>> 
> >>>> To accomplish what you want you just need to set up filtering in your
configuration so that the FATAL-INFO events go to one Appender and the DEBUG and TRACE events
go to another Appender.
> >>>> 
> >>>> Ralph
> >>>> 
> >>>>> On Dec 14, 2015, at 8:34 AM, Nicholas Duane <nickdu@msn.com>
wrote:
> >>>>> 
> >>>>> I'm curious if there is such a thing as a StatusAppender in log4j2
which, as you would guess, is the appender the StatusLogger would use?
> >>>>> 
> >>>>> Here's what I'm trying to solve, I think.
> >>>>> 
> >>>>> I've been telling other developers I work with that a piece of code
should only write to a single logger.  The reason for this, in my mind, is that if a piece
of code writes to more than one logger then it essentially has routing logic in it and I would
rather have the routing in the configuration.  For example:
> >>>>> 
> >>>>> try
> >>>>>  {
> >>>>>  logger1.info(...);
> >>>>>  .
> >>>>>  .
> >>>>>  .
> >>>>>  logger2.debug(...);
> >>>>>  }
> >>>>> catch(Exception e)
> >>>>>  {
> >>>>>  logger1.error(...);
> >>>>>  }
> >>>>> 
> >>>>> The above code is sending debug events to a different logger than
the rest of the events it raises.  I would rather have the code send all events to a single
logger and control where those events are routed via the configuration.  Feel free to let
me know whether this is in line with logging principles.
> >>>>> 
> >>>>> So here's the problem.  We've got some code which writes events
to its logger.  We want to capture these events centrally so we're sending them to a central
location via an HTTP appender.  We want to do this only for FATAL - INFO events, so we're
not expecting a huge load.  DEBUG events however, we'd like to send to the same location as
the status logger.  We can, of course, just add a console appender for DEBUG events but that
would have to be controlled separately from the status logger and ideally it would be nice
to just piggy back on the status logger.  We could have this code write to its private logger
and the status logger for DEBUG events, but then we get into the routing issue I mentioned
above.  So I'm wondering, is there such a thing as a StatusAppender?
> >>>>> 
> >>>>> Thanks,
> >>>>> Nick
> >>>> 
> >>>> 
> >>>> 
> >>>> ---------------------------------------------------------------------
> >>>> 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
> 
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message